<html>
<head><meta charset="utf-8"><title>Stability and visibility · project-safe-transmute · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/index.html">project-safe-transmute</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html">Stability and visibility</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="208723943"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208723943" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208723943">(Sep 01 2020 at 17:59)</a>:</h4>
<p>I'm reading through the RFC, and I'm feeling uneasy about 1) the sheer size of the API, and 2) any attempt to talk about visibility/stability with the trait system.</p>
<p>That is, I don't believe stability ought to be reified into std- today, it is determined purely by the set of visible items (both <code>pub</code> and <code>impl</code> based). Thus, instead of the <code>PromiseTransmutable..</code> and <code>NeglectStability</code> stuff, I would expect "public"/"stable" transmutability to use "plain old impls" of an option-less version of <code>Transmute..</code> (like how <code>Copy</code> is not an auto trait either), and "private" transmutability to be performed <em>without</em> going through a trait, e.g. via a lang-item based directly on implicit constructibility.</p>
<p>IIUC, this would limit the public/"vocabulary" API to <em>just</em> a deriv-able <code>Transmute..</code>, with no option parameters or extra traits. The static checks on alignment/etc would be left up to the "private" non-trait-based mechanism, to be used within those impls. Does this sound reasonable, or am I missing something subtle?</p>



<a name="208723963"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208723963" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208723963">(Sep 01 2020 at 17:59)</a>:</h4>
<p>(Side note: I am probably missing a lot of details here! I wish there were more of a separate "problem statement" that described what the RFC is trying to accomplish <em>without</em> reference to <code>PromiseTransmutable..</code>/<code>NeglectStability</code>- as it is, I am having to untangle those goals from the way the RFC proposes to accomplish them.)</p>



<a name="208746069"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208746069" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208746069">(Sep 01 2020 at 20:47)</a>:</h4>
<p>It's important to me that we do not conflate safety with stability. This RFC allows you to query the safety of a transmutation independent from its stability:</p>
<ul>
<li><code>Dst: TransmuteFrom&lt;Src, NeglectStability&gt;</code> if <code>Src</code> to <code>Dst</code> is safe</li>
</ul>
<p>It sounds like you are describing an alternative where instances of a <code>TransmuteFrom</code> trait are only available for types whose author has annotated them with <code>derive(Transmute)</code>. This deeply intertwines safety and stability. A type <code>Dst</code> would be <code>TransmuteFrom&lt;Src&gt;</code> only if the authors of <code>Dst</code> and <code>Src</code> annotated their types with <code>derive(Transmute)</code>, and if the transmutation  from <code>Src</code> to <code>Dst</code> was safe.</p>
<p>This wouldn't avoid the issue of transmutation stability so much as it would make it inescapable.</p>



<a name="208746265"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208746265" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208746265">(Sep 01 2020 at 20:49)</a>:</h4>
<p>In contrast to the stability system proposed by our RFC, this alternative system is all-or-nothing. You could not, for instance, use it to bound the stable size or alignment of your type.</p>



<a name="208746865"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208746865" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208746865">(Sep 01 2020 at 20:54)</a>:</h4>
<p>As for <code>Neglect</code>: the ability to turn off static checks is what makes our proposal a useful foundation for a range of other effort. The ability to neglect the alignment check is going to be bytemuck's bread-and-butter (cc <span class="user-mention" data-user-id="224471">@Lokathor</span>). The ability to neglect the validity check is going to make possible a range of <em>fallible</em> transmutation abstractions (cc <span class="user-mention" data-user-id="264680">@Tristan Hume</span>).</p>



<a name="208747080"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747080" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747080">(Sep 01 2020 at 20:56)</a>:</h4>
<p>And, the ability to <code>NeglectStability</code> is going to make possible benefitting from this RFC's mechanisms without waiting for all of one's dependencies to catch up. Without it, you'd need to fall back to a <em>totally</em> unsafe alternative if confronted with a transmute-unstable type.</p>



<a name="208747253"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747253" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747253">(Sep 01 2020 at 20:57)</a>:</h4>
<p><span class="user-mention" data-user-id="219211">@Jack Wrenn</span> what did you think of adding a size-match requirement with a Neglect to turn it off?</p>



<a name="208747347"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747347" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747347">(Sep 01 2020 at 20:57)</a>:</h4>
<p><span class="user-mention" data-user-id="224471">@Lokathor</span> that does not seem relevant to this thread...</p>



<a name="208747449"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747449" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747449">(Sep 01 2020 at 20:58)</a>:</h4>
<p>size changes in a type accidentally turning into a truncation were specifically called out in the rfc thread as a form of stability hazard</p>



<a name="208747537"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747537" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747537">(Sep 01 2020 at 20:59)</a>:</h4>
<p><span class="user-mention" data-user-id="219211">@Jack Wrenn</span> Yes, I am describing an alternative where <code>TransmuteFrom</code> must be implemented by the type author. But no, that does not intertwine safety and stability- <code>TransmuteFrom</code> would represent stability, and a non-trait lang-item-y mechanism would represent safety.</p>



<a name="208747616"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747616" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747616">(Sep 01 2020 at 20:59)</a>:</h4>
<p>This is not all-or-nothing! This is simply sticking to the existing idioms of Rust- you can still do all the same things, you just divide up the responsibilities differently.</p>



<a name="208747755"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747755" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747755">(Sep 01 2020 at 21:00)</a>:</h4>
<p>The point is, this amount of API complexity has a massive cost, and it is <em>not</em> a necessary part of the compiler providing the static checks described in the RFC.</p>



<a name="208747898"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747898" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747898">(Sep 01 2020 at 21:01)</a>:</h4>
<p>I made the comparison to <code>Copy</code> very deliberately- <code>Copy</code> is a <em>stability</em> guarantee, but positions in the program that have access to private details can still perform the copy operation without the trait!</p>



<a name="208747987"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208747987" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208747987">(Sep 01 2020 at 21:01)</a>:</h4>
<p>What sort of non-trait lang-item-y mechanism are you envisioning? <code>TransmuteFrom</code> is a trait lang item. We use a trait, as opposed to a function intrinsic, to expose transmutation safety, because traits can be abstracted over.</p>



<a name="208748349"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208748349" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208748349">(Sep 01 2020 at 21:04)</a>:</h4>
<p>That abstraction is the source of my concern. As soon as you put something in the trait system it ceases to have anything to do with visibility, and so an auto-impled lang item trait simply cannot be used to enforce visibility-related invariants. It would be more appropriate to use a language feature that <em>can</em> take visibility into account- e.g. a "magic" function (like how <code>mem::transmute</code> enforces matching size), or even new syntax (analogous to how <code>SomeStruct { fields }</code> is language-level syntax).</p>



<a name="208748672"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208748672" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208748672">(Sep 01 2020 at 21:07)</a>:</h4>
<blockquote>
<p>so an auto-impled lang item trait simply cannot be used to enforce visibility-related invariants</p>
</blockquote>
<p>Yes, hence the RFC's formulation of safety-via-constructability, and the stability declaration traits.</p>



<a name="208748831"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208748831" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208748831">(Sep 01 2020 at 21:08)</a>:</h4>
<p>Ultimately, the ability to build abstractions over transmutations is a core design goal of this RFC. We could (and did) consider realizing certain aspects of the RFC as intrinsic predicates, but those fail to address the requirement of abstraction-building.</p>



<a name="208749394"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208749394" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208749394">(Sep 01 2020 at 21:12)</a>:</h4>
<blockquote>
<p>We could (and did) consider realizing certain aspects of the RFC as intrinsic predicates, but those fail to address the requirement of abstraction-building.</p>
</blockquote>
<p>I am not convinced of this. With intrinsics/syntax you may need to introduce new traits outside of std for each particular use case, but that doesn't actually <em>prevent</em> any abstraction-building AFAICT. Arguably, moving that kind of abstraction-building out of std is <em>exactly</em> the way to shrink the RFC and get a minimum viable feature set.</p>



<a name="208750124"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208750124" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> glowcoil <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208750124">(Sep 01 2020 at 21:17)</a>:</h4>
<p>I share the concerns about introducing so much complexity to deal with the semver problem. The way I see it, this RFC introduces a very wide-reaching change (a trait that is auto-derived for a huge number of types), which would make it so that changes to struct layouts are breaking changes, and then introduces a significant amount of complexity to the trait API to fix this problem. If the trait were not pervasively auto-derived in the first place, and instead opt-in (like Copy), it would interact with semver in a standard way like other traits.</p>



<a name="208750206"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208750206" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208750206">(Sep 01 2020 at 21:18)</a>:</h4>
<p>I am confident that the <a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#towards-an-initial-smart-implementation">initial smart implementation</a> of this RFC <em>is</em> a minimal viable feature set. It either addresses or can gracefully evolve to address (e.g., via adding additional neglectable checks) all of the use-cases considered by this working group.</p>
<p>I am very reluctant to recommend adopting an API that <em>cannot</em> grow to accomodate use-cases considered by this working-group; that would seem to imply that we might have to eventually design an <em>alternative</em> safe-transmute API to accomodate those use-cases.</p>



<a name="208752877"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208752877" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208752877">(Sep 01 2020 at 21:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="284949">glowcoil</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208750124">said</a>:</p>
<blockquote>
<p>(a trait that is auto-derived for a huge number of types), which would make it so that changes to struct layouts are breaking changes</p>
</blockquote>
<p>This is a great way to put it! The existence of <code>TransmuteFrom&lt;T, NeglectStability&gt;</code> makes certain layout changes (which were previously minor semver changes) breaking, with no opt-out- or in other words, it punches a new hole through the usual usage of <code>pub</code> and <code>impl</code> to manage stability.</p>
<p>The initial smart implementation <em>does</em> avoid this by downgrading <code>NeglectStability</code> to <code>unsafe</code>. But my argument is that <code>NeglectStability</code> should stay that way forever: Either a type author should explicitly impl <code>TransmuteFrom</code> (basically "marking some of its layout <code>pub</code>", analogous to impling <code>Copy</code>), or else the type's layout should stay entirely private, and only safely transmutable from positions where it is implicitly constructible.</p>
<p>Notably this last condition is actually much more powerful than even the full version of <code>TransmuteFrom&lt;T, NeglectStability&gt;</code>. It would let you do safe transmutes in the type's module <em>even with private fields</em>, while still preventing outside modules from doing so. The trait system, OTOH, can't express this no matter how much compiler magic you throw at it, because traits impls don't have their own visibility.</p>



<a name="208754165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208754165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208754165">(Sep 01 2020 at 21:57)</a>:</h4>
<p>Coming at this from the "API size" angle again, this makes <code>NeglectStability</code> feel like it exists solely as a short-term workaround for people who want to work with types that a) have documented their layout but b) have not yet implemented <code>Promise..</code>. This feels analogous to a hypothetical <code>NeglectNotCopy</code>- the correct solution is to add the impl, and we already have the tools to do that! (i.e. cargo patch)</p>



<a name="208759824"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208759824" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208759824">(Sep 01 2020 at 23:01)</a>:</h4>
<blockquote>
<p>The existence of <code>TransmuteFrom&lt;T, NeglectStability&gt;</code> makes certain layout changes (which were previously minor semver changes) breaking, with no opt-out- or in other words, it punches a new hole through the usual usage of <code>pub</code> and <code>impl</code> to manage stability.</p>
</blockquote>
<p>This is simply incorrect. <strong>You have to <em>opt-in</em> to neglecting stability.</strong> Stability is not neglected unless you type the words <code>NeglectStability</code>.</p>
<hr>
<blockquote>
<p>The initial smart implementation does avoid this by downgrading <code>NeglectStability</code> to <code>unsafe</code>.</p>
</blockquote>
<p>No, that's not at all why the initial smart implementation does this. We do it because the simple formulation of constructability has a soundness hole, not because <code>unsafe</code> discourages people from doing a thing.</p>
<hr>
<blockquote>
<p>or else the type's layout should stay entirely private</p>
</blockquote>
<p>This does not accurately describe the status quo. You can observe and rely on potentially unstable aspects of a type's layout <em>already</em>, in safe code; <a href="https://doc.rust-lang.org/core/mem/fn.size_of.html"><code>size_of</code></a> and <a href="https://doc.rust-lang.org/core/mem/fn.align_of.html"><code>align_of</code></a> are trivial cases of this.</p>
<hr>
<blockquote>
<p>Notably this last condition is actually much more powerful than even the full version of TransmuteFrom&lt;T, NeglectStability&gt;. It would let you do safe transmutes in the type's module even with private fields, while still preventing outside modules from doing so.</p>
</blockquote>
<p>The full formulation of constructability in the RFC permits exactly this scenario, because checking for implicit constructability intrinsically relates to scope.</p>
<hr>
<blockquote>
<p>The trait system, OTOH, can't express this no matter how much compiler magic you throw at it, because traits impls don't have their own visibility.</p>
</blockquote>
<p>Scope resolution occurs, necessarily, <em>before</em> trait resolution. It is absolutely possible for trait resolution to take scope into account. This isn't unprecedented: it's more or less how Haskell's <code>Coercible</code> typeclass works. We acknowledge it may not be <em>easy</em> to do this, which is why we propose a simplified formulation of constructability as a candidate for initial implementation.</p>



<a name="208761372"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208761372" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208761372">(Sep 01 2020 at 23:21)</a>:</h4>
<p>This is quickly becoming quite combative, so I'll respond to some misunderstandings but leave the actual subject matter alone for now.</p>



<a name="208761496"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208761496" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208761496">(Sep 01 2020 at 23:22)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208759824">said</a>:</p>
<blockquote>
<p>This is simply incorrect. <strong>You have to opt-in to neglect stability.</strong> Stability is not neglected unless you type the words <code>NeglectStability</code>.</p>
</blockquote>
<p>You misunderstand. "You" here is the type user, but up until this point "you" has always been, instead, the type author. To be perfectly clear:</p>
<p>Today, if crate A 1.0 defines a type like this...</p>
<div class="codehilite"><pre><span></span><code><span class="cp">#[repr(C)]</span><span class="w"></span>
<span class="k">pub</span><span class="w"> </span><span class="k">struct</span> <span class="nc">Pair</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">pub</span><span class="w"> </span><span class="n">a</span>: <span class="kt">i8</span><span class="p">,</span><span class="w"> </span><span class="k">pub</span><span class="w"> </span><span class="n">b</span>: <span class="kt">i32</span> <span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>...then crate A 1.1 can change that to look like this...</p>
<div class="codehilite"><pre><span></span><code><span class="cp">#[repr(C)]</span><span class="w"></span>
<span class="k">pub</span><span class="w"> </span><span class="k">struct</span> <span class="nc">Pair</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">pub</span><span class="w"> </span><span class="n">b</span>: <span class="kt">i32</span><span class="p">,</span><span class="w"> </span><span class="k">pub</span><span class="w"> </span><span class="n">a</span>: <span class="kt">i8</span> <span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>...without breaking crate B, because today nobody can safely transmute a <code>Pair</code>. Automatically implementing <code>TransmuteFrom&lt;Pair, NeglectStability&gt;</code> is a totally new possibility- you can of course argue that <code>NeglectStability</code> shifts the blame for any breakage onto crate B, but that doesn't change the fact that a change in crate A that used to be perfectly innocuous may now break crate B. That's all I meant here.</p>



<a name="208761645"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208761645" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208761645">(Sep 01 2020 at 23:24)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208759824">said</a>:</p>
<blockquote>
<p>No, that's not at all why the initial smart implementation does this. We do it because the simple formulation of constructability has a soundness hole, not because <code>unsafe</code> discourages people from doing a thing.</p>
</blockquote>
<p>I never claimed that was <em>why</em> the initial smart implementation makes <code>NeglectStability</code> unsafe, only that doing so happens to avoid the breakage described above, if you squint at the unsafe obligations in a particular way.</p>



<a name="208761647"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208761647" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208761647">(Sep 01 2020 at 23:24)</a>:</h4>
<p>If crate B is transmuting, pointer casting, or otherwise reinterpreting <code>Pair</code>, then yes, that change will be breaking (in the sense that it silently causes UB).</p>



<a name="208761672"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208761672" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208761672">(Sep 01 2020 at 23:24)</a>:</h4>
<p>Sigh.</p>



<a name="208761909"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208761909" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208761909">(Sep 01 2020 at 23:28)</a>:</h4>
<p>The RFC views stability as basically orthogonal to stability. As part of our MVP, we position stability as an <em>extension</em> of safety, but <a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#stability-of-unsafe-transmutations">we explore how even this restriction might be lifted in the future</a>.</p>



<a name="208761912"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208761912" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208761912">(Sep 01 2020 at 23:28)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208759824">said</a>:</p>
<blockquote>
<p>This does not accurately describe the status quo. You can observe and rely on potentially unstable aspects of a type's layout <em>already</em>, in safe code; <a href="https://doc.rust-lang.org/core/mem/fn.size_of.html"><code>size_of</code></a> and <a href="https://doc.rust-lang.org/core/mem/fn.align_of.html"><code>align_of</code></a> are trivial cases of this.</p>
</blockquote>
<p>Doing so will not, today, break compilation of crate B unless they are doing unsafe things. Changing the size of a type is not, per se, a capitalized Breaking Change, while <code>NeglectStability</code> will convert it into one. On the other hand, if crate A type authors must opt into certain size/align-dependent operations being explicitly available (e.g. by implementing <code>TransmuteFrom</code>), then making those changes Breaking is perfectly fine.</p>



<a name="208762098"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762098" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762098">(Sep 01 2020 at 23:31)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208759824">said</a>:</p>
<blockquote>
<p>Scope resolution occurs, necessarily, <em>before</em> trait resolution. It is absolutely possible for trait resolution to take scope into account. This isn't unprecedented: it's more or less how Haskell's <code>Coercible</code> typeclass works. We acknowledge it may not be <em>easy</em> to do this, which is why we propose a simplified formulation of constructability as a candidate for initial implementation.</p>
</blockquote>
<p><em>Trait</em> resolution relying on scope is fine, because it does not change the set of available impls for a given trait. <em>Impl</em> resolution, on the other hand, <em>cannot ever</em> depend on scope, without introducing serious and subtle soundness holes.  If a (post-scope-resolution) trait is implemented for a (post-scope-resolution) type in one location, it <em>absolutely must</em> be implemented for it in all locations, and vice versa.</p>



<a name="208762210"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762210" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762210">(Sep 01 2020 at 23:32)</a>:</h4>
<p>(And all locations must further use the <em>same</em> impl.)</p>



<a name="208762405"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762405" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762405">(Sep 01 2020 at 23:35)</a>:</h4>
<p>Relaxing this, as GHC's Coercible class does, is a <em>major</em> change to the trait system in its own right and should not be used as justification to toss in future extensions to an RFC...</p>



<a name="208762481"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762481" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762481">(Sep 01 2020 at 23:36)</a>:</h4>
<blockquote>
<p>Doing so will not, today, break compilation of crate B unless they are doing unsafe things.</p>
</blockquote>
<p>Counterpoint:</p>
<div class="codehilite"><pre><span></span><code><span class="k">mod</span> <span class="nn">crate_a</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="c1">// try to change the size of `Foo` without breaking `crate_b`</span>
<span class="w">    </span><span class="k">pub</span><span class="w"> </span><span class="k">struct</span> <span class="nc">Foo</span><span class="p">([</span><span class="kt">u8</span><span class="p">;</span><span class="w"> </span><span class="mi">2</span><span class="p">]);</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>

<span class="k">mod</span> <span class="nn">crate_b</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">use</span><span class="w"> </span><span class="n">core</span>::<span class="n">mem</span>::<span class="n">size_of</span><span class="p">;</span><span class="w"></span>
<span class="w">    </span><span class="c1">// no unsafe code here</span>
<span class="w">    </span><span class="k">const</span><span class="w"> </span><span class="n">_</span>: <span class="p">[();</span><span class="w"> </span><span class="n">size_of</span>::<span class="o">&lt;</span><span class="k">super</span>::<span class="n">crate_a</span>::<span class="n">Foo</span><span class="o">&gt;</span><span class="p">()]</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[();</span><span class="w"> </span><span class="mi">2</span><span class="p">];</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="208762486"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762486" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762486">(Sep 01 2020 at 23:36)</a>:</h4>
<p>Indeed, even with that change, GHC still includes "type roles" as a way for type authors to control this.</p>



<a name="208762600"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762600" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762600">(Sep 01 2020 at 23:38)</a>:</h4>
<p>That's a fair example, though I will note that it is the cause of much anguish in other parts of the language already, so on its own it's still not an argument to go further in that direction.</p>



<a name="208762779"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762779" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762779">(Sep 01 2020 at 23:41)</a>:</h4>
<blockquote>
<p>it is the cause of much anguish in other parts of the language already</p>
</blockquote>
<p>Is this true? It doesn't seem self-evident to me.</p>



<a name="208762827"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762827" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762827">(Sep 01 2020 at 23:42)</a>:</h4>
<p>I'm referring to, for example, <code>extern type</code>.</p>



<a name="208762999"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208762999" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208762999">(Sep 01 2020 at 23:45)</a>:</h4>
<p>I am not advocating rust <em>ever</em> adopt a <em>general</em> mechanism for scope-dependent impls, and I acknowledge it's no small change.  However, there's a difference between hard and theoretically unsound. The situation you describe does not point to this being theoretically unsound, just unsound given the <em>current</em> implementation of trait resolution. This RFC is emphatically about having the trait resolution system do things it currently doesn't, like assess the layouts of types.</p>
<p>(My understanding of roles is that they are needed moreso because GHC reasons about type definitions, not type layouts.)</p>



<a name="208763160"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208763160" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208763160">(Sep 01 2020 at 23:47)</a>:</h4>
<p>Overall, our biggest difference does seem to be this expectation that the trait system may eventually be capable of hiding impls based on scope. With that, then <code>NeglectStability</code> has a path forward, and my concern would primarily be about the unwieldiness of the API. Without that, <code>NeglectStability</code> has no reason to exist, and my concern is that the RFC is biting off more than it can chew.</p>



<a name="208763910"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208763910" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208763910">(Sep 01 2020 at 23:58)</a>:</h4>
<p>Some other factors in why I would not bet on this trait system extension necessarily being possible:</p>
<ul>
<li>GHC classes and Rust traits are quite similar in some ways but they are very different in others, <em>especially</em> surrounding coherence/object safety/variance/specialization/etc.</li>
<li>GHC, as you say, does not reason about type layouts- its value representation is uniform and GCed, so it can simply ignore the size/alignment/padding/ownership/etc concerns that are Rust's bread and butter.</li>
<li>Expanding on the first point a bit, Rust already has a lot of uncertainty to deal with around <em>future</em> trait system features- specialization, negative impls, interactions with async and const, generic and defaulted associated types, etc. (See e.g. <a href="https://github.com/rust-lang/rust/issues/71550">#71550</a> for a soundness bug arising from the interaction between object safety, variance, and associated types.)</li>
</ul>



<a name="208764094"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208764094" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208764094">(Sep 02 2020 at 00:00)</a>:</h4>
<blockquote>
<p>Overall, our biggest difference does seem to be this expectation that the trait system may eventually be capable of hiding impls based on scope.</p>
</blockquote>
<p>That seems about right. I think of it more as, <em>the trait system generates impls on-the-fly (in part) based on scope</em>, but I <em>think</em> that's pretty similar to "hiding impls based on scope". </p>
<p>I wouldn't necessarily say I have an <em>expectation</em> that the trait system will eventually be capable of this, but rather that it seems <em>plausible</em> that it <em>could</em> within the next few <em>decades</em>. If it ever does, then the compiler's implementation of this RFC will match the platonic ideal of it—without needing to overhaul the RFC's API surface at all. </p>
<p>Until then, the simplified formulation is constructability is still a pretty damn good proxy for safety. The impact of its pub-in-priv soundness hole feels quite small: it <em>just</em> means that <code>NeglectStability</code> is an unsafe transmute option for the time being. Can you clarify how this amounts to <code>NeglectStability</code> having "no reason to exist"?</p>



<a name="208765605"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208765605" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208765605">(Sep 02 2020 at 00:20)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208764094">said</a>:</p>
<blockquote>
<p>Can you clarify how this amounts to <code>NeglectStability</code> having "no reason to exist"?</p>
</blockquote>
<p>In the spirit of "clarify intent but leave the subject matter alone for now:"</p>
<ul>
<li>In its initial unsafe form, <code>NeglectStability</code> is basically just a placeholder in the API, pending future extensions that make it safe.</li>
<li>In its safe but non-scope-based form, it foists a new kind of (yes, opt-in for clients) breaking change on the ecosystem, all to get around a missing upstream impl that should be added anyway. (Or not added, in which case <code>NeglectStability</code> shouldn't be used anyway!)</li>
<li>Only with its final, hypothetical, scope-based form do we gain something immediately useful- generic code <em>in the type's scope</em> using <code>TransmuteFrom&lt;T, NeglectStability&gt;</code> bounds that are inaccessible to other scopes.</li>
</ul>
<p>So what I mean is, <code>NeglectStability</code> et al are quite a lot of surface area to add to an MVP, on the off chance that we can eventually within "decades" implement the final form.</p>



<a name="208766286"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208766286" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208766286">(Sep 02 2020 at 00:30)</a>:</h4>
<p>(I'm sorry to keep prodding you on this, but you keep saying interesting things!)</p>



<a name="208766609"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208766609" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208766609">(Sep 02 2020 at 00:34)</a>:</h4>
<p>So: I do <em>not</em> view <code>NeglectStability</code> as an option with a ton of associated machinery. Rather, I view the stability system as a bunch of machinery, with an associated <code>NeglectStability</code> option.</p>
<p>The stability system lets users make very fine grained stability promises about their types, and have the implications of those promises automatically enforced by the trait system (and without any compiler magic!). It <em>also</em> happens to be sometimes convenient to turn off, so the RFC provides a mechanism for doing so.</p>
<p>In terms of raw expressive power, yes, <code>NeglectStability</code> seems like it might not bring much to the table: you can always just vendor your dependencies  and add the stability promises to the necessary types. (Can crates with vendored dependencies be published to <a href="http://crates.io">crates.io</a>?)</p>



<a name="208766926"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208766926" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> glowcoil <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208766926">(Sep 02 2020 at 00:39)</a>:</h4>
<p>My opinion regarding the stability system overall is that Rust already has a stability system, in the form of item visibility and semver, and it would be preferable to me to design a safe transmute API so that it dovetails with these existing systems rather than effectively emulating them using traits and witnesses.</p>



<a name="208767353"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208767353" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208767353">(Sep 02 2020 at 00:47)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208766609">said</a>:</p>
<blockquote>
<p>So: I do <em>not</em> view <code>NeglectStability</code> as an option with a ton of associated machinery. Rather, I view the stability system as a bunch of machinery, with an associated <code>NeglectStability</code> option.</p>
</blockquote>
<p>This is a distinction a) without a difference and b) that I was not trying to make. (Thus "<code>NeglectStability</code> <em>et al</em>.") You should be able to accomplish essentially the same things, fine-grained layout descriptions and all, without <em>any</em> of that machinery, just using the existing idiom of "a plain old trait impl is a promise about the type." Vendored deps shouldn't even come into this.</p>
<p>If a type author wishes to export a fine-grained guarantee about their type's layout, they should be able to <code>impl TransmuteFrom&lt;ThatType&gt; for SomeArchetype</code>- all the <code>Promise..</code>/<code>NeglectStability</code> machinery folds away, and the archetype thing becomes nothing more than a useful design pattern. (Which, to be clear, I do quite like!)</p>
<p>On the other hand, if a type author wishes <em>not</em> to export anything about their type's layout, that is not a reason to add a "convenience" hole in the visibility system! We don't have an equivalent way to bypass missing <code>Copy</code> impls- we just expect clients to file a bug and/or do the copy "by hand" (e.g. <code>let new_data = Data { old_data.field1, old_data.field2 }</code>).</p>



<a name="208768157"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208768157" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208768157">(Sep 02 2020 at 01:00)</a>:</h4>
<blockquote>
<p>You should be able to accomplish essentially the same things, fine-grained layout descriptions and all, without any of that machinery, just using the existing idiom of "a plain old trait impl is a promise about the type."</p>
</blockquote>
<p>I'm having a hard time envisioning how this would work, since a key component of the current visibility system is specifying archetypes that exemplify the bounds of the stability promise. I'd like to see a proposal more fully fleshing this idea out.</p>
<blockquote>
<p>Vendored deps shouldn't even come into this.</p>
</blockquote>
<p>I only bring it up because that's only the solution to the "the-impls-don't-exist" case if dependencies are involved and you can't <code>NeglectStability</code>. <a href="https://github.com/rust-lang/libc/issues/471#issuecomment-266541262">libc would be a prominent cause of this scenario</a>.</p>
<blockquote>
<p>On the other hand, if a type author wishes not to export anything about their type's layout, that is not a reason to add a "convenience" hole in the visibility system!</p>
</blockquote>
<p>I think we're really responding to a hole that <em>already exists</em>: the current bit-reinterpretation conversion mechanisms do not have any concept of stability. Let's say we drop <code>NeglectStability</code>: if you cannot vendor your dependency and add impls for the stability declaration traits, your <em>only</em> recourse will be to continue to use those wildly-unsafe transmutation mechanisms. In our RFC, the <code>NeglectStability</code> option provides a safer alternative.</p>



<a name="208768423"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208768423" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208768423">(Sep 02 2020 at 01:04)</a>:</h4>
<p><span class="user-mention silent" data-user-id="284949">glowcoil</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208766926">said</a>:</p>
<blockquote>
<p>My opinion regarding the stability system overall is that Rust already has a stability system, in the form of item visibility and semver, and it would be preferable to me to design a safe transmute API so that it dovetails with these existing systems rather than effectively emulating them using traits and witnesses.</p>
</blockquote>
<p>I do not feel that we are emulating SemVer with traits and witnesses. The item visibility and semver rules, as laid out in prior RFCs, do not make substantial promises about a type's layout.</p>
<p>So, rather than try to come up with entirely new semver rules relating to transmutation, we just reuse the existing mechanisms.  The current SemVer rules <em>do</em> talk about what is a breaking change when a trait is implemented. We reify the stability promise as two traits which end-users implement. Those traits follow all the normal rules of semver stability.</p>



<a name="208984243"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208984243" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208984243">(Sep 03 2020 at 15:24)</a>:</h4>
<p>(I do intend to come back to this, this is just a really busy week for me at work. I would love to write up some examples to clarify how things might work with an opt-in <code>TransmuteFrom</code> -- <span class="user-mention" data-user-id="219211">@Jack Wrenn</span> let me know if you have any specific cases that would be helpful to see.)</p>



<a name="208984423"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208984423" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208984423">(Sep 03 2020 at 15:25)</a>:</h4>
<p>Will do! I've also just written a <em>Gentle Introduction to Transmutation Stability</em> which hopefully provides some more context of what the RFC is even talking about: <a href="https://jack.wrenn.fyi/blog/transmutation-stability/">https://jack.wrenn.fyi/blog/transmutation-stability/</a></p>



<a name="208984814"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/208984814" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#208984814">(Sep 03 2020 at 15:28)</a>:</h4>
<p>That's what prompted me to leave this message, actually -- I appreciate the clarification and wish I'd had it when first reading the RFC. (Though I think my response is still warranted :P)</p>



<a name="209172458"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209172458" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209172458">(Sep 05 2020 at 10:48)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208984423">said</a>:</p>
<blockquote>
<p>Will do! I've also just written a <em>Gentle Introduction to Transmutation Stability</em> which hopefully provides some more context of what the RFC is even talking about: <a href="https://jack.wrenn.fyi/blog/transmutation-stability/">https://jack.wrenn.fyi/blog/transmutation-stability/</a></p>
</blockquote>
<p>FWIW something seems to be broken in the markup, one paragraph reads <code>Rust's auto traits (</code> and then ends.</p>



<a name="209172520"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209172520" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209172520">(Sep 05 2020 at 10:50)</a>:</h4>
<p>regarding the general discussion here, <code>NeglectStability</code> indeed seems like a big can of worms and I wonder if it really has to be part of the MVP</p>



<a name="209177554"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209177554" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209177554">(Sep 05 2020 at 13:16)</a>:</h4>
<blockquote>
<p>FWIW something seems to be broken in the markup, one paragraph reads Rust's auto traits ( and then ends.</p>
</blockquote>
<p>gah, weird. I could have sworn I fixed that. it's DEFINITELY fixed now</p>



<a name="209177593"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209177593" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209177593">(Sep 05 2020 at 13:17)</a>:</h4>
<blockquote>
<p>I wonder if it really has to be part of the MVP</p>
</blockquote>
<p><a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#minimal-useful-stabilization-surface"><code>NeglectStability</code> does not need to be part of the stable MVP for this RFC to be broadly useful.</a></p>



<a name="209187959"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209187959" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209187959">(Sep 05 2020 at 17:32)</a>:</h4>
<p>We should be able to go even further than that, and make both <code>NeglectStability</code> and <code>Promise..</code> <em>forever</em> unnecessary without giving up on important use cases, and make the API smaller and more idiomatic in the process:</p>
<p>The core idea is to move "implicit constructability" from the trait system into the visibility system. Syntactically it might look similar to <code>mem::transmute</code> or <code>as</code>. For <em>monomorphic</em> types <code>Dst</code> and <code>Src</code>, it would allow construction of a <code>Dst</code> value from a <code>Src</code> value iff <code>Dst</code> is implicitly constructable from <code>Src</code> at the current position. (I'm leaving cross-module implicit constructability intentionally vague for the moment- see "layout visibility" below.)</p>
<p>Up front, doing this without a trait appears to lose two things: polymorphism over the presence or absence of <code>NeglectStability</code>, and polymorphism over un-annotated implicitly constructable types. However, the first seems extraneous, and the RFC only actually provides the second via a <em>very</em> hypothetical extension to the trait system (impls whose existence depends on source location). Further, if Rust does ever get that extension, this approach could use it just as readily as the RFC! (Again, see below for details.)</p>



<a name="209187960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209187960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209187960">(Sep 05 2020 at 17:32)</a>:</h4>
<p>On the other hand, this notably does <em>not</em> lose fine-grained control over stability guarantees orthogonal to safety, polymorphism over <em>annotated</em> transmutable types, or future extensibility:</p>
<ul>
<li>To understand how this approach handles safety+stability, think in terms of the "layout visibility" I mentioned above. I see three design choices here: leave all layouts private and only make them public with impls, retroactively make public the layouts of <code>#[repr(..)]</code> types, or add new syntax to declare layout public (e.g. <code>#[repr(pub, C)]</code>). Either way, the goal is to give type authors control over whether the type is implicitly constructible <em>outside</em> its module.</li>
<li>Building on this, we can recover fine-grained stability annotations <em>and</em> polymorphic safe transmutes by re-introducing a simpler, option-less <code>TransmuteFrom</code> trait! The RFC's excellent archetype pattern still works here- a type author can <code>impl Transmute{From,Into}&lt;MainType&gt; for ItsArchetype</code>, where <code>ItsArchetype</code> has public layout, enabling other modules+crates to work with <code>ItsArchetype</code> in their transmutes.<ul>
<li>libcore could still provide a convenience wrapper for archetype&lt;-&gt;archetype transmutes, with an extra <code>trait PublicLayout { type Archetype: Transmute{From,Into}&lt;Self&gt;; }</code>. But this doesn't need to be in the MVP to provide the actual fine-grained control!</li>
</ul>
</li>
<li>If Rust ever does gain location-dependent impls, this approach can take advantage of them by adding bounds to its core intrinsic. This would be similar to adding <code>where size_of::&lt;T&gt;() == size_of::&lt;U&gt;()</code> to <code>mem::transmute</code>- it simply becomes usable on polymorphic types. These bounds don't need to be related to <code>TransmuteFrom</code> <em>at all</em>- so this poses no risk of a "whoops, time to replace the entire safe transmute API" scenario.</li>
</ul>



<a name="209188915"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209188915" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209188915">(Sep 05 2020 at 18:00)</a>:</h4>
<p>Another thing I left vague above, because there are several possible approaches, is the <em>rest</em> of the <code>Neglect..</code> options. They're still possible, even without the options parameter to <code>Transmute..</code>!</p>
<p>For the core intrinsic itself, we have a few options- split it up into multiple functions, give the intrinsic itself an RFC-like options parameter, etc.</p>
<p>For polymorphic partially-safe transmutes, I will for now just note that the RFC's examples for <code>NeglectAlignment</code> and <code>NeglectValidity</code> should be able to use the core intrinsics directly- the validity example just goes between two monomorphic types (<code>u8</code> and <code>Bool</code>), and the alignment example only needs to know that <code>T</code> and <code>U</code> are transmutable <em>on their own</em> in order to transmute references to them.</p>
<p>(This last one also has precedent with <code>mem::transmute</code>, which <em>can</em> handle polymorphic types like <code>&amp;T</code> -&gt; <code>&amp;U</code> because the "top level" which determines the size is known.)</p>



<a name="209192590"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209192590" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209192590">(Sep 05 2020 at 19:34)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> </p>
<blockquote>
<p>NeglectStability indeed seems like a big can of worms</p>
</blockquote>
<p>Not sure I follow; what's the can of worms?</p>



<a name="209192823"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209192823" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209192823">(Sep 05 2020 at 19:39)</a>:</h4>
<p><span class="user-mention silent" data-user-id="132362">Joshua Liebow-Feeser</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209192590">said</a>:</p>
<blockquote>
<p>Not sure I follow; what's the can of worms?</p>
</blockquote>
<p>The worm under discussion so far is that it basically punches a hole through the usual privacy/stability rules- rather than the type author controlling whether their type is transmutable (a la the explicit opt in to implement the Copy trait), now crate <em>clients</em> can do that without their involvement.</p>
<p>And while the RFC starts it out as unsafe, and provides a technically-sound way to make it safe, and at least makes it opt-in on the part of the type <em>user</em>, it still departs from the usual idioms around privacy+stability, which are "the type author decides what is public and what is private."</p>



<a name="209192874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209192874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209192874">(Sep 05 2020 at 19:40)</a>:</h4>
<p>See e.g. this reply <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208766926">https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/208766926</a></p>



<a name="209193181"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209193181" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209193181">(Sep 05 2020 at 19:48)</a>:</h4>
<blockquote>
<p>The worm under discussion so far is that it basically punches a hole through the usual privacy/stability rules- rather than the type author controlling whether their type is transmutable (a la the explicit opt in to implement the Copy trait), now crate clients can do that without their involvement.</p>
</blockquote>
<p>Doesn't the fact that <code>NeglectStability</code> is unsafe just put this on the same footing as pointer casting or <code>mem::transmute</code>, both of which allow you to punch the hole you're describing so long as you use <code>unsafe</code>?</p>



<a name="209193197"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209193197" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> HeroicKatora <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209193197">(Sep 05 2020 at 19:49)</a>:</h4>
<p>As described in the RFC, <code>NeglectStability</code> is _not_ unsafe to use. It implements <code>SafeTransmuteOptions</code>.<br>
<a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#neglecting-static-checks">https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#neglecting-static-checks</a></p>



<a name="209193207"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209193207" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209193207">(Sep 05 2020 at 19:49)</a>:</h4>
<p>It's technically <em>initially</em> unsafe to use. I say it should be eventually safe because, in principle, safety is orthogonal to stability.</p>
<p>In this, I'm following the pattern of <code>mem::align_of</code> and <code>mem::size_of</code>. These functions are safe, callable with any type, but their output should not be considered stable across even minor crate versions.</p>
<p>(However, whereas these functions don't really call attention to their instability, <code>TransmuteFrom</code> does: you need to actually type the words <code>NeglectStability</code> to make it behave unlike a "normal" trait with respect to stability.)</p>



<a name="209193209"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209193209" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209193209">(Sep 05 2020 at 19:49)</a>:</h4>
<p><span class="user-mention silent" data-user-id="229913">HeroicKatora</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209193197">said</a>:</p>
<blockquote>
<p>As described in the RFC, <code>NeglectStability</code> is _not_ unsafe to use. It implements <code>SafeTransmuteOptions</code>.<br>
<a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#neglecting-static-checks">https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#neglecting-static-checks</a></p>
</blockquote>
<p>It starts out unsafe in the MVP, is what I'm referring to.</p>



<a name="209193580"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209193580" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209193580">(Sep 05 2020 at 19:58)</a>:</h4>
<p>Right, so referring to the MVP, can you clarify how this is different than unions, pointer casting, or <code>mem::transmute</code>, which allow this sort of breaking-the-visibility-wall today? I'm not sure I see the difference.</p>



<a name="209193878"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209193878" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209193878">(Sep 05 2020 at 20:05)</a>:</h4>
<p>Well, it may be unsafe in the MVP but it still has a different (smaller) proof obligation- "the type author documented this type's layout as stable" instead of the full obligation of <code>mem::transmute</code> et al. And if you aren't supposed to use <code>NeglectStability</code> without the type author's opt-in, then why does it even exist to begin with? Why not just have the type author add the right impls?</p>



<a name="209193886"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209193886" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209193886">(Sep 05 2020 at 20:05)</a>:</h4>
<p>(Copy works the same way- we don't have a "please let me copy this even though the author didn't impl Copy" tool, we just make a PR or use cargo's patch feature or whatever.)</p>



<a name="209194003"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194003" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194003">(Sep 05 2020 at 20:08)</a>:</h4>
<blockquote>
<p>(Copy works the same way- we don't have a "please let me copy this even though the author didn't impl Copy" tool, we just make a PR or use cargo's patch feature or whatever.)</p>
</blockquote>
<p><code>ptr::read</code> lets you do this.</p>



<a name="209194017"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194017" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194017">(Sep 05 2020 at 20:08)</a>:</h4>
<p>(And, by extension, <code>transmute_copy</code>)</p>



<a name="209194035"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194035" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194035">(Sep 05 2020 at 20:09)</a>:</h4>
<p>That's not what ptr::read or transmute_copy are <em>for</em>, though- they target different use cases and only provide that functionality incidentally and in a totally unchecked way.</p>



<a name="209194079"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194079" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194079">(Sep 05 2020 at 20:10)</a>:</h4>
<p>They provide no justification to extend the equivalent escape hatch here, mem::transmute, into NeglectStability</p>



<a name="209194206"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194206" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194206">(Sep 05 2020 at 20:14)</a>:</h4>
<p>That may be the case, but there are explicit reasons that you want to be able to neglect stability: namely, if you are operating in the same crate in which a type is defined. On Fuchsia (the project I work on, and the project for which I created the <code>zerocopy</code> crate), we do this all the time.</p>



<a name="209194222"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194222" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194222">(Sep 05 2020 at 20:15)</a>:</h4>
<p>If it's only for use within the same crate, then that job belongs to the visibility system, not the trait system. And then you get to my big spiel above about just exposing safe transmutability directly as an intrinsic.</p>



<a name="209194276"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194276" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194276">(Sep 05 2020 at 20:16)</a>:</h4>
<p>That lets you "neglect stability" (or rather handle it by existing in the same unit of versioning) <em>safely</em>, in an MVP instead of gated on a hypothetical trait system extension.</p>



<a name="209194508"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194508" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194508">(Sep 05 2020 at 20:24)</a>:</h4>
<p>Ah I see your point. I believe there are still scenarios in which visibility alone doesn't cut it. Imagine you have a type which is public, and all of its fields are public. You may want to not promise stability of its layout, while still relying on its layout internally in your crate. Since the type is publicly constructible (in other words, it's visible as are all of its fields), you can't use the visibility system to allow you to make this distinction.</p>



<a name="209194513"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194513" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194513">(Sep 05 2020 at 20:25)</a>:</h4>
<p>My big spiel above addresses that issue.</p>



<a name="209194562"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194562" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194562">(Sep 05 2020 at 20:26)</a>:</h4>
<p>Type layout is a separate thing that should have its own visibility, and code that can see it would be able to rely on its layout while code that cannot would have to go through its API, which may or may not include a Transmute.. impl</p>



<a name="209194578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194578">(Sep 05 2020 at 20:27)</a>:</h4>
<p><code>transmute_copy</code> and <code>ptr::read</code> already ignore visibility, but they're unsafe <em>because</em> they're so unchecked, so instead of allowing a partly or fully checked way to accomplish those tasks... we should just not improve the situation at all? That's an unacceptable position</p>



<a name="209194584"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194584" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194584">(Sep 05 2020 at 20:27)</a>:</h4>
<p>That's not my position!</p>



<a name="209194624"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194624" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194624">(Sep 05 2020 at 20:28)</a>:</h4>
<p>then I have misunderstood you</p>



<a name="209194641"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194641" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194641">(Sep 05 2020 at 20:29)</a>:</h4>
<p>My position is that type authors need to retain control over the visibility of their type's layout, using the same rules and patterns as anything else with a visibility.</p>



<a name="209194684"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194684" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194684">(Sep 05 2020 at 20:30)</a>:</h4>
<blockquote>
<p>Type layout is a separate thing that should have its own visibility, and code that can see it would be able to rely on its layout while code that cannot would have to go through its API, which may or may not include a Transmute.. impl</p>
</blockquote>
<p>Ah I understand now. That could work, but it would be a significant language change. It strikes me that the MVP proposed by the RFC is much simpler. Not to suggest that we don't want something like that eventually; we definitely might! But it would require a lot of careful design, and I don't think including it in this RFC is the best way of going about that.</p>



<a name="209194698"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194698" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194698">(Sep 05 2020 at 20:30)</a>:</h4>
<p>It may be a larger language change than the RFC's MVP, but it's overall a <em>much much</em> smaller language change than the RFC's "selective impl visibility" stuff.</p>



<a name="209194708"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194708" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194708">(Sep 05 2020 at 20:31)</a>:</h4>
<p>And it enables what I believe to be a much nicer API. :)</p>



<a name="209194709"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194709" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194709">(Sep 05 2020 at 20:31)</a>:</h4>
<blockquote>
<p>My position is that type authors need to retain control over the visibility of their type's layout, using the same rules and patterns as anything else with a visibility.</p>
</blockquote>
<p>and NeglectVisibility doesn't oppose that position. It says "i dont care if it breaks later, just do it now".</p>



<a name="209194721"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194721" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194721">(Sep 05 2020 at 20:31)</a>:</h4>
<p>If I thought NeglectStability were consistent with my position, why would I be saying otherwise? Please try not to make brick-wall claims like this.</p>



<a name="209194769"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194769" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194769">(Sep 05 2020 at 20:33)</a>:</h4>
<p>That ability to say "I don't care if it breaks later" is <em>new</em> and <em>not something we should encourage</em>. If you need to access a type's layout, either convince the crate's author to make it (partially) public, or patch the crate yourself. This is no different from any other trait- Copy, Clone, Send, Sync, etc.</p>



<a name="209194782"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194782" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194782">(Sep 05 2020 at 20:33)</a>:</h4>
<p>it is <em>not new</em> it's just <code>transmute_copy</code> but safer</p>



<a name="209194787"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194787" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194787">(Sep 05 2020 at 20:33)</a>:</h4>
<p>transmute_copy is not intended for use as a "let me ignore stability" tool- using it as one is unsound!</p>



<a name="209194791"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194791" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194791">(Sep 05 2020 at 20:34)</a>:</h4>
<p>^ I suspect that without <code>NeglectStability</code>, people will just <em>keep using</em> <code>transmute</code> and <code>transmute_copy</code>.</p>



<a name="209194832"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194832" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194832">(Sep 05 2020 at 20:34)</a>:</h4>
<p>And I don't think using it as such is unsound.</p>



<a name="209194834"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194834" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194834">(Sep 05 2020 at 20:34)</a>:</h4>
<p>A bad idea, yes.</p>



<a name="209194846"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194846" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194846">(Sep 05 2020 at 20:34)</a>:</h4>
<p>It is unsound unless you can somehow enforce that you are always built using an exact version of your dependency.</p>



<a name="209194852"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194852" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194852">(Sep 05 2020 at 20:35)</a>:</h4>
<p>Otherwise you need to see your code as, in a sense, polymorphic over all the versions you might ever be built against.</p>



<a name="209194854"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194854" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194854">(Sep 05 2020 at 20:35)</a>:</h4>
<p>You say "somehow", but pinning deps is <em>really</em> easy.</p>



<a name="209194857"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194857" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194857">(Sep 05 2020 at 20:35)</a>:</h4>
<p>It's easy in cargo, but it's impossible in rust proper.</p>



<a name="209194858"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194858" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Liebow-Feeser <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194858">(Sep 05 2020 at 20:35)</a>:</h4>
<p>The important distinction is that, if you depend on a type's layout using <code>transmute</code> or <code>transmute_copy</code>, and then the layout changes, your code will continue to compile, but it will be unsound. With <code>NeglectStability</code>, it will stop compiling. That's a <em>very</em> important distinction.</p>



<a name="209194859"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194859" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194859">(Sep 05 2020 at 20:35)</a>:</h4>
<p>And I don't think that's strictly true, either. E.g., You can use <code>transmute</code> to newtype and un-newtype a foreign type, regardless of whether that foreign type has made any documented stability promises.</p>



<a name="209194913"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194913" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194913">(Sep 05 2020 at 20:37)</a>:</h4>
<p><span class="user-mention silent" data-user-id="132362">Joshua Liebow-Feeser</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209194858">said</a>:</p>
<blockquote>
<p>The important distinction is that, if you depend on a type's layout using <code>transmute</code> or <code>transmute_copy</code>, and then the layout changes, your code will continue to compile, but it will be unsound. With <code>NeglectStability</code>, it will stop compiling. That's a <em>very</em> important distinction.</p>
</blockquote>
<p>That is an important distinction, but it's not completely true! It may continue to compile and do something weird.</p>



<a name="209194916"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194916" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194916">(Sep 05 2020 at 20:37)</a>:</h4>
<p>if you want to talk about rust in the absence of cargo, there's no concept of version anyway.</p>



<a name="209194921"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194921" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194921">(Sep 05 2020 at 20:37)</a>:</h4>
<p>rust without cargo gets weird fast</p>



<a name="209194991"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209194991" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209194991">(Sep 05 2020 at 20:39)</a>:</h4>
<p>This is quickly getting into the weeds, but my overall point is, "people who would just use <code>transmute_copy</code>" should <em>not</em> be our target audience as language designers! We should not be holding a bucket in a rainstorm trying to maximize the number of poor decisions we can make accidentally-correct.</p>



<a name="209195053"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195053" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195053">(Sep 05 2020 at 20:40)</a>:</h4>
<p>If people <em>are</em> overusing <code>transmute_copy</code>, then we should look at their use cases and address them directly, not give them the exact same tool with <em>slightly</em> more static checks, which still let them break things.</p>



<a name="209195055"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195055" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195055">(Sep 05 2020 at 20:40)</a>:</h4>
<p>Vendoring a dependency to add an impl to it is a big undertaking. I think people faced with the prospect of doing that will probably just continue to use whatever old wildly unsafe mechanism they're using. It's far easier to <em>pin</em> a dependency, and use <code>NeglectStability</code>.</p>



<a name="209195083"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195083" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195083">(Sep 05 2020 at 20:41)</a>:</h4>
<p>It is not a big undertaking <em>at all</em>! We just had this discussion over in this thread: <a href="#narrow/stream/122651-general/topic/querying.20type.20niche.20status">https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/querying.20type.20niche.20status</a></p>



<a name="209195093"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195093" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195093">(Sep 05 2020 at 20:41)</a>:</h4>
<p>All you have to do is git clone, add the impl, and then add a [patch] section to your cargo.toml.</p>



<a name="209195105"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195105" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195105">(Sep 05 2020 at 20:42)</a>:</h4>
<blockquote>
<p>Type layout is a separate thing that should have its own visibility</p>
</blockquote>
<p>The RFC, quite intentionally, does not attempt to define "layout" (rather, it focuses on the definition of _transmutability_). We don't talk about the layouts of types being visible or private, but instead of transmutations being stable, or unstable (or unsafe, or unsound).</p>
<p>Some aspects of a type's layout are <em>already</em> observable in completely safe code (e.g., size and alignment), and even more are observable with unsafe code. Designing a notion of "visible layout" that's compatible with the current state of Rust, and useful for transmutations, is a non-trivial task. I'm not confident that attempting this would make the RFC smaller.</p>



<a name="209195159"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195159" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195159">(Sep 05 2020 at 20:42)</a>:</h4>
<p>When I say "layout visibility" I'm not attempting to imply <em>any</em> new definition work. I'm using it to refer to, precisely, the RFC's definition of scope-dependent implicit constructibility.</p>



<a name="209195169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195169">(Sep 05 2020 at 20:43)</a>:</h4>
<p>People <em>are</em> overusing <code>transmute_copy</code>. And we <em>did</em> look at their use cases. This project has been going on quite a while, it is not an RFC out of the blue.</p>



<a name="209195171"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195171" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195171">(Sep 05 2020 at 20:43)</a>:</h4>
<p>The difference between what I call public and private visibility is exactly the same difference as the RFC's "PromiseTransmutable.." impls.</p>



<a name="209195277"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195277" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195277">(Sep 05 2020 at 20:45)</a>:</h4>
<p>I'm quite happy with the RFC's definition of transmutability- that aspect seems to be quite direct and useful. All I'm trying to discuss here is how it's exposed in the language, because what I see in the RFC seems deeply unidiomatic and overly complex.</p>



<a name="209195423"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195423" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195423">(Sep 05 2020 at 20:48)</a>:</h4>
<p>If I'm inadvertently breaking a use case <em>other</em> than "I want to ignore a foreign type's lack of publicly-guaranteed transmutability," I'm happy to explore the design space there. But that particular use case simply is not something I'm willing to entertain- we <em>already have</em> multiple solutions to that problem, and we should apply them here as well.</p>



<a name="209195452"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195452" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195452">(Sep 05 2020 at 20:50)</a>:</h4>
<p>Can you clarify what about the API you feel is "deeply unidomatic"?</p>



<a name="209195494"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195494" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195494">(Sep 05 2020 at 20:50)</a>:</h4>
<p>(At the absolute minimum, if those solutions seem insufficient, then any extensions to them ought to be in their <em>own</em> RFC, not riders on the safe transmute RFC.)</p>



<a name="209195513"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195513" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195513">(Sep 05 2020 at 20:51)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209195452">said</a>:</p>
<blockquote>
<p>Can you clarify what about the API you feel is "deeply unidomatic"?</p>
</blockquote>
<p>Nothing that hasn't already been said- it's trying to do the visibility system's job in the trait system, and then adding an escape hatch to make up for the trait system's inability to fully do that job. If something should be private, <em>make it private</em>, don't just hide it behind <code>NeglectStability</code>.</p>



<a name="209195568"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195568" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195568">(Sep 05 2020 at 20:53)</a>:</h4>
<p><code>NeglectStability</code> isn't an escape hatch for the trait system. It's there because stability and safety are <em>fundamentally</em> orthogonal.</p>



<a name="209195574"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195574" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195574">(Sep 05 2020 at 20:53)</a>:</h4>
<p>I am running out of ways to say this: nothing I'm proposing conflates stability and safety.</p>



<a name="209195581"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195581" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195581">(Sep 05 2020 at 20:53)</a>:</h4>
<p>It merely aligns the way they are expressed with the rest of the language.</p>



<a name="209195622"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195622" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195622">(Sep 05 2020 at 20:54)</a>:</h4>
<p>Are you proposing any mechanism that allows safe transmutations that are not stable?</p>



<a name="209195629"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195629" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195629">(Sep 05 2020 at 20:54)</a>:</h4>
<p>Yes! Please read my giant response above! :(</p>



<a name="209195693"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195693" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195693">(Sep 05 2020 at 20:56)</a>:</h4>
<p>For example, a "tell" to me that NeglectStability <em>is</em> an escape hatch is that <span class="user-mention" data-user-id="132362">@Joshua Liebow-Feeser</span> mentioned the use case of "use it in the same crate as the type definition." With my giant spiel above, that is a non-issue, because you can just use the core intrinsic and it will decide whether the transmutation is allowed <em>directly</em> based on visibility, the same way <code>TransmuteFrom&lt;T, NeglectStability&gt;</code> would in the full version of the RFC.</p>



<a name="209195786"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195786" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195786">(Sep 05 2020 at 20:59)</a>:</h4>
<p>In other words, instead of forcing the transmute-er to manually decide whether they want to use the type's public or private API, we should simply select the correct API based on source position, and close the escape hatch of the transmute-er deciding on the private API when they should not.</p>



<a name="209195797"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195797" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195797">(Sep 05 2020 at 20:59)</a>:</h4>
<p>If it helps simplify what I'm trying to suggest, you might (loosely) think of it as "make <code>TransmuteFrom&lt;T, NeglectStability&gt;</code> into an intrinsic like <code>mem::transmute</code>, and build the rest on top of that."</p>



<a name="209195846"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195846" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195846">(Sep 05 2020 at 21:00)</a>:</h4>
<p>That's more or less how I already think of it.</p>
<p>See line 132 here: <a href="https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=1ff1700e6dba595f1e600d20da5d6387">https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=1ff1700e6dba595f1e600d20da5d6387</a></p>



<a name="209195854"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195854" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195854">(Sep 05 2020 at 21:00)</a>:</h4>
<p>Er, no, I specifically mean "an intrinsic which is not a trait impl" because that is a very very important distinction.</p>



<a name="209195855"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195855" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195855">(Sep 05 2020 at 21:01)</a>:</h4>
<p>I imagine that that impl is swapped out with a compiler supported one. Everything else is built on top of that.</p>



<a name="209195873"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195873" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195873">(Sep 05 2020 at 21:01)</a>:</h4>
<p>And the reason I use the trait impl as the intrinsic, rather than some <code>can_transmute</code> predicate  is because traits can be abstracted over. A primary goal of this RFC is to create an API surface with abstractions can be built.</p>



<a name="209195919"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195919" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195919">(Sep 05 2020 at 21:02)</a>:</h4>
<p>I also address that in my giant spiel- abstraction is not really necessary at this level, and brings with it a major cost- it forces the operation to become universally available, opening the hole I keep complaining about.</p>



<a name="209195979"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195979" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195979">(Sep 05 2020 at 21:04)</a>:</h4>
<p>Can you sketch out the API surface you think would work?</p>



<a name="209195987"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195987" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195987">(Sep 05 2020 at 21:04)</a>:</h4>
<p>I tried to do so in my giant spiel.</p>



<a name="209195995"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195995" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195995">(Sep 05 2020 at 21:05)</a>:</h4>
<p>If your design can't be used to make abstractions that sounds poor</p>



<a name="209195997"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209195997" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209195997">(Sep 05 2020 at 21:05)</a>:</h4>
<p>Yes, but with code.</p>



<a name="209196010"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196010" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196010">(Sep 05 2020 at 21:05)</a>:</h4>
<p><span class="user-mention" data-user-id="224471">@Lokathor</span> it can be used to make abstractions, that's my entire point...</p>



<a name="209196018"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196018" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196018">(Sep 05 2020 at 21:05)</a>:</h4>
<p>(You also mentioned ditching the <code>Neglect</code> parameter of <code>TransmuteFrom</code>, and I'm not sure how that all fits into this.)</p>



<a name="209196066"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196066" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196066">(Sep 05 2020 at 21:06)</a>:</h4>
<p>Not so much ditching as moving out of the trait system.</p>



<a name="209196095"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196095" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196095">(Sep 05 2020 at 21:07)</a>:</h4>
<p>...but traits are Rust's primary abstraction mechanism for working with types.</p>



<a name="209196100"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196100" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196100">(Sep 05 2020 at 21:07)</a>:</h4>
<p>Can't do generics without traits</p>



<a name="209196101"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196101" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196101">(Sep 05 2020 at 21:07)</a>:</h4>
<p><span class="user-mention" data-user-id="219211">@Jack Wrenn</span> I'm not sure what code you're asking for. I'm suggesting that the MVP only needs to be a single new intrinsice: <code>fn safe_transmute&lt;T, U&gt;(t: T) -&gt; U</code>, which is callable in precisely the same circumstances as <code>TransmuteFrom&lt;T, NeglectStability&gt; for U</code> would exist.</p>



<a name="209196141"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196141" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196141">(Sep 05 2020 at 21:08)</a>:</h4>
<p>If I want to use that function in a generic context, I'm going to need to repeat whatever <code>where</code> bound is on it.</p>



<a name="209196151"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196151" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196151">(Sep 05 2020 at 21:09)</a>:</h4>
<p>If there's no <code>where</code> bound that constrains its types, then it seems about as useful for abstractions as <code>mem::transmute</code>.</p>



<a name="209196156"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196156" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196156">(Sep 05 2020 at 21:09)</a>:</h4>
<p>It starts with no where bounds, like mem::transmute, just like the RFC starts with no way to use NeglectStability safely. If Rust ever gets position-dependent impls, then its where bounds can become something like <code>where U: MagicalTransmuteFrom&lt;T&gt;</code></p>



<a name="209196162"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196162" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196162">(Sep 05 2020 at 21:09)</a>:</h4>
<p>Are there any traits at all in your MVP?</p>



<a name="209196164"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196164" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196164">(Sep 05 2020 at 21:09)</a>:</h4>
<p>There don't need to be! :)</p>



<a name="209196210"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196210" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196210">(Sep 05 2020 at 21:10)</a>:</h4>
<p>How do I build abstractions like <a href="https://github.com/rust-lang/project-safe-transmute/blob/master/rfcs/0000-ext-container-casting.md">Slice Casting</a> on top of it then?</p>



<a name="209196211"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196211" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196211">(Sep 05 2020 at 21:10)</a>:</h4>
<p>You can implement something like PromiseTransmutable.. purely in userspace on top of that intrinsic. You could include it in an initial implementation if it's more convenient, or leave it up to the ecosystem if there is still room for designing.</p>



<a name="209196218"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196218" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196218">(Sep 05 2020 at 21:11)</a>:</h4>
<p>how do you make it so that a library transmutes a user's type for them?</p>



<a name="209196219"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196219" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196219">(Sep 05 2020 at 21:11)</a>:</h4>
<p><code>PromiseTransmutableInto</code> looks like this:</p>
<div class="codehilite"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="k">trait</span><span class="w"> </span><span class="n">PromiseTransmutableInto</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">type</span> <span class="nc">Archetype</span>: <span class="nc">TransmuteFrom</span><span class="o">&lt;</span><span class="bp">Self</span><span class="p">,</span><span class="w"> </span><span class="n">NeglectStability</span><span class="o">&gt;</span><span class="p">;</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>It's only safe because I can bound the <code>Archetype</code> with a trait. What bound would I put there in your proposal?</p>



<a name="209196265"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196265" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196265">(Sep 05 2020 at 21:12)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209196218">said</a>:</p>
<blockquote>
<p>how do you make it so that a library transmutes a user's type for them?</p>
</blockquote>
<p>Require them to implement a trait. The impl is non-polymorphic and can use the intrinsic; the library dispatches via the trait.</p>



<a name="209196281"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196281" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196281">(Sep 05 2020 at 21:13)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209196219">said</a>:</p>
<blockquote>
<p><code>PromiseTransmutableInto</code> looks like this:<br>
[...]<br>
It's only safe because I can bound the <code>Archetype</code> with a trait. What bound would I put there in your proposal?</p>
</blockquote>
<p>Replace the associated type with a call to the intrinsic. It provides the same sort of proof discharge.</p>



<a name="209196285"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196285" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196285">(Sep 05 2020 at 21:13)</a>:</h4>
<p>(I covered this in the middle bullet point of the spiel.)</p>



<a name="209196322"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196322" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196322">(Sep 05 2020 at 21:14)</a>:</h4>
<p><a href="https://docs.rs/generic-array/0.14.4/generic_array/">generic-array</a> is probably going to want to write an impl like this:</p>
<div class="codehilite"><pre><span></span><code><span class="k">impl</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"> </span><span class="n">PromiseTransmutableFrom</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">GenericArray</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">T</span>: <span class="nc">PromiseTransmutableFrom</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">N</span>: <span class="nc">ArrayLength</span><span class="o">&lt;</span><span class="n">T</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>

<span class="w">    </span><span class="c1">// for lack of implied bounds, we must repeat the bounds on `Archetype`:</span>
<span class="w">    </span><span class="n">GenericArray</span><span class="o">&lt;</span><span class="n">T</span>::<span class="n">Archetype</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"></span>
<span class="w">        </span>: <span class="nc">TransmuteInto</span><span class="o">&lt;</span><span class="bp">Self</span><span class="p">,</span><span class="w"> </span><span class="n">NeglectStability</span><span class="o">&gt;</span><span class="w"></span>
<span class="w">        </span><span class="o">+</span><span class="w"> </span><span class="n">PromiseTransmutableFrom</span><span class="p">,</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">type</span> <span class="nc">Archetype</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">GenericArray</span><span class="o">&lt;</span><span class="n">T</span>::<span class="n">Archetype</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="p">;</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="209196324"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196324" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196324">(Sep 05 2020 at 21:14)</a>:</h4>
<p>what's the intrinsic call?</p>



<a name="209196452"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196452" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196452">(Sep 05 2020 at 21:18)</a>:</h4>
<p>Something like this:</p>
<div class="codehilite"><pre><span></span><code><span class="k">impl</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">U</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"> </span><span class="n">TransmutableFrom</span><span class="o">&lt;</span><span class="n">GenericArray</span><span class="o">&lt;</span><span class="n">U</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">GenericArray</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"> </span><span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">T</span>: <span class="nc">PublicLayout</span><span class="o">&lt;</span><span class="n">Archetype</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">U</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">N</span>: <span class="nc">ArrayLength</span><span class="o">&lt;</span><span class="n">T</span><span class="o">&gt;</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">fn</span> <span class="nf">transmute_from</span><span class="p">(</span><span class="n">t</span>: <span class="nc">GenericArray</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="nc">GenericArray</span><span class="o">&lt;</span><span class="n">U</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">        </span><span class="n">safe_transmute</span><span class="p">(</span><span class="n">t</span><span class="p">)</span><span class="w"></span>
<span class="w">    </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="209196460"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196460" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196460">(Sep 05 2020 at 21:19)</a>:</h4>
<p>You own GenericArray there, so you get access to whatever NeglectStability would.</p>



<a name="209196518"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196518" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196518">(Sep 05 2020 at 21:20)</a>:</h4>
<p>That is, the intrinsic can see GenericArray, and it can see into its fields, so the only "tricky" part here is when it hits the T-&gt;U transmute.</p>



<a name="209196533"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196533" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196533">(Sep 05 2020 at 21:21)</a>:</h4>
<p>Transmutation isn't just about transmutation, though. Calling <code>transmute</code> isn't always a meaningful thing to do.</p>
<p>It's not sensible in the case of slice casting:</p>
<div class="codehilite"><pre><span></span><code><span class="k">fn</span> <span class="nf">cast</span><span class="o">&lt;</span><span class="na">&#39;i</span><span class="p">,</span><span class="w"> </span><span class="na">&#39;o</span><span class="p">,</span><span class="w"> </span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Dst</span><span class="o">&gt;</span><span class="p">(</span><span class="n">src</span>: <span class="kp">&amp;</span><span class="na">&#39;i</span><span class="w"> </span><span class="p">[</span><span class="n">Src</span><span class="p">])</span><span class="w"> </span>-&gt; <span class="kp">&amp;</span><span class="na">&#39;o</span><span class="w"> </span><span class="p">[</span><span class="n">Dst</span><span class="p">]</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="o">&amp;</span><span class="na">&#39;o</span><span class="w"> </span><span class="p">[</span><span class="n">Dst</span><span class="p">;</span><span class="w"> </span><span class="mi">1</span><span class="p">]</span>: <span class="nc">TransmuteFrom</span><span class="o">&lt;&amp;</span><span class="na">&#39;i</span><span class="w"> </span><span class="p">[</span><span class="n">Src</span><span class="p">;</span><span class="w"> </span><span class="kt">usize</span>::<span class="n">MAX</span><span class="p">]</span><span class="o">&gt;</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="kd">let</span><span class="w"> </span><span class="n">len</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">size_of_val</span><span class="p">(</span><span class="n">src</span><span class="p">).</span><span class="n">checked_div</span><span class="p">(</span><span class="n">size_of</span>::<span class="o">&lt;</span><span class="n">Dst</span><span class="o">&gt;</span><span class="p">()).</span><span class="n">unwrap_or</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span><span class="w"></span>
<span class="w">    </span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">slice</span>::<span class="n">from_raw_parts</span><span class="p">(</span><span class="n">src</span><span class="p">.</span><span class="n">as_ptr</span><span class="p">()</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="n">Dst</span><span class="p">,</span><span class="w"> </span><span class="n">len</span><span class="p">)</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>and it's DEFINITELY not sensible with an <code>AlignLtEq</code> trait:</p>
<div class="codehilite"><pre><span></span><code><span class="sd">/// Implemented if `align_of::&lt;Self&gt;() &lt;= align_of::&lt;Rhs&gt;()`</span>
<span class="k">pub</span><span class="w"> </span><span class="k">trait</span><span class="w"> </span><span class="n">AlignLtEq</span><span class="o">&lt;</span><span class="n">Rhs</span><span class="p">,</span><span class="w"> </span><span class="n">Neglect</span><span class="o">=</span><span class="p">()</span><span class="o">&gt;</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">Neglect</span>: <span class="nc">TransmuteOptions</span><span class="p">,</span><span class="w"></span>
<span class="p">{}</span><span class="w"></span>

<span class="k">impl</span><span class="o">&lt;</span><span class="n">Lhs</span><span class="p">,</span><span class="w"> </span><span class="n">Rhs</span><span class="p">,</span><span class="w"> </span><span class="n">Neglect</span><span class="o">&gt;</span><span class="w"> </span><span class="n">AlignLtEq</span><span class="o">&lt;</span><span class="n">Rhs</span><span class="p">,</span><span class="w"> </span><span class="n">Neglect</span><span class="o">&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">Lhs</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">Neglect</span>: <span class="nc">TransmuteOptions</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="k">for</span><span class="o">&lt;</span><span class="na">&#39;a</span><span class="o">&gt;</span><span class="w"> </span><span class="o">&amp;</span><span class="na">&#39;a</span><span class="w"> </span><span class="p">[</span><span class="n">Lhs</span><span class="p">;</span><span class="w"> </span><span class="mi">0</span><span class="p">]</span>: <span class="nc">TransmuteFrom</span><span class="o">&lt;&amp;</span><span class="na">&#39;a</span><span class="w"> </span><span class="p">[</span><span class="n">Rhs</span><span class="p">;</span><span class="w"> </span><span class="mi">0</span><span class="p">],</span><span class="w"> </span><span class="n">Neglect</span><span class="o">&gt;</span><span class="w"></span>
<span class="p">{}</span><span class="w"></span>
</code></pre></div>


<p>In these examples, trait bound is used as a proof of some property for purposes other than transmutation.</p>



<a name="209196574"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196574" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196574">(Sep 05 2020 at 21:22)</a>:</h4>
<p>To avoid punching holes in the visibility system, that T-&gt;U transmute should only be performable by this code if either a) T and U have visible layouts here, which requires the hypothetical trait system extension to write a bound for, or b) T and U have exposed their layouts via a TransmuteFrom impl.</p>



<a name="209196626"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196626" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196626">(Sep 05 2020 at 21:24)</a>:</h4>
<p><span class="user-mention silent" data-user-id="117495">rpjohnst</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209196452">said</a>:</p>
<blockquote>
<p>Something like this:</p>
<div class="codehilite"><pre><span></span><code><span class="k">impl</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">U</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"> </span><span class="n">TransmutableFrom</span><span class="o">&lt;</span><span class="n">GenericArray</span><span class="o">&lt;</span><span class="n">U</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">GenericArray</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"> </span><span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">T</span>: <span class="nc">PublicLayout</span><span class="o">&lt;</span><span class="n">Archetype</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">U</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">N</span>: <span class="nc">ArrayLength</span><span class="o">&lt;</span><span class="n">T</span><span class="o">&gt;</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">fn</span> <span class="nf">transmute_from</span><span class="p">(</span><span class="n">t</span>: <span class="nc">GenericArray</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="nc">GenericArray</span><span class="o">&lt;</span><span class="n">U</span><span class="p">,</span><span class="w"> </span><span class="n">N</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">        </span><span class="n">safe_transmute</span><span class="p">(</span><span class="n">t</span><span class="p">)</span><span class="w"></span>
<span class="w">    </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


</blockquote>
<p>Does <code>safe_transmute</code> have any static restrictions on its type parameters, or is it only callable in a monomorphic context like <code>mem_transmute</code>? If it either of these are true, this won't compile.</p>



<a name="209196629"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196629" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196629">(Sep 05 2020 at 21:24)</a>:</h4>
<p>(This does imply that some use cases will need the intrinsic to understand and use a <code>TransmuteFrom</code> trait.)</p>



<a name="209196639"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196639" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196639">(Sep 05 2020 at 21:24)</a>:</h4>
<p><code>mem::transmute</code> is not only callable in monomorphic contexts. You can, for example, transmute a &amp;T to a &amp;U.</p>



<a name="209196645"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196645" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196645">(Sep 05 2020 at 21:25)</a>:</h4>
<p>Only because it effectively erases those types away!</p>



<a name="209196648"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196648" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196648">(Sep 05 2020 at 21:25)</a>:</h4>
<p>Doesn't mean a new intrinsic couldn't pay attention to them. ;)</p>



<a name="209196695"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196695" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196695">(Sep 05 2020 at 21:26)</a>:</h4>
<p>...and thus be subject to the same monomorphization restriction?</p>



<a name="209196701"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196701" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196701">(Sep 05 2020 at 21:26)</a>:</h4>
<p>No, see my parenthetical- there's no reason it can't look for trait impls on them.</p>



<a name="209196761"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196761" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196761">(Sep 05 2020 at 21:28)</a>:</h4>
<p>At this point, let me propose a thought experiment: Imagine a hybrid of the RFC with this approach, where the lang-item is a trait like the RFC, but the trait has no options parameter. Instead, there are two traits- TransmuteFromPrivate and TransmuteFrom. Does <em>this</em> change on its own seem plausible to you, at least?</p>



<a name="209196770"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196770" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196770">(Sep 05 2020 at 21:29)</a>:</h4>
<p>I don't like it, but I can imagine it.</p>



<a name="209196822"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196822" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196822">(Sep 05 2020 at 21:30)</a>:</h4>
<p>That's the direction I'm aiming for with the non-trait version. Remove knobs and dials and hole-punches from the primary <code>TransmuteFrom</code> trait, and isolate them to impl bodies.</p>



<a name="209196828"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196828" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196828">(Sep 05 2020 at 21:30)</a>:</h4>
<p>The knobs and dials are kinda important.</p>



<a name="209196831"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196831" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196831">(Sep 05 2020 at 21:30)</a>:</h4>
<p>But not for every use case!</p>



<a name="209196835"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196835" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196835">(Sep 05 2020 at 21:31)</a>:</h4>
<p>That's why the <code>Neglect</code> parameter is defaulted.</p>



<a name="209196836"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196836" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196836">(Sep 05 2020 at 21:31)</a>:</h4>
<p>Mostly they are important in the "glue" that enables the actual end use cases.</p>



<a name="209196840"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196840" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196840">(Sep 05 2020 at 21:31)</a>:</h4>
<p>Defaulting is perhaps better than forcing everyone to write (), but it does not close the visibility hole.</p>



<a name="209196883"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196883" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196883">(Sep 05 2020 at 21:32)</a>:</h4>
<p>It may well be that my version is worse than the trait version when it comes to implementing the glue. But I'm not starting from the premise that we must use a function rather than a trait! I'm starting from the premise that we must re-use and integrate with Rust's existing mechanisms for stability.</p>



<a name="209196889"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196889" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196889">(Sep 05 2020 at 21:33)</a>:</h4>
<p>Which, before anyone contradicts that again, <code>NeglectStability</code> does <em>not</em> do.</p>



<a name="209196939"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196939" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196939">(Sep 05 2020 at 21:34)</a>:</h4>
<p>(I'm just about out of time for this discussion today; hopefully I conveyed at least a little of what I intended to. I can discuss this more another time.)</p>



<a name="209196940"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196940" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196940">(Sep 05 2020 at 21:34)</a>:</h4>
<p>I don't view this issue as at all novel. What's the distinction between the impl <code>Dst: TransmuteFrom&lt;Src, NeglectStability</code> not being stable, and the return value of  <code>align_of</code>/<code>size_of</code> not being stable?</p>



<a name="209196942"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196942" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196942">(Sep 05 2020 at 21:34)</a>:</h4>
<p>The whole point of this RFC is to lift aspects of layout into the trait system.</p>



<a name="209196951"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196951" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196951">(Sep 05 2020 at 21:35)</a>:</h4>
<p>It's not surprising that the same instabilities would apply.</p>



<a name="209196957"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209196957" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209196957">(Sep 05 2020 at 21:35)</a>:</h4>
<p>If anything, the "idiomatic" thing to do would be, like those <code>mem</code> intrinsics, to make no attempt to close the stability hole at all!</p>



<a name="209197000"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197000" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197000">(Sep 05 2020 at 21:36)</a>:</h4>
<p>Alright I'll answer that one. <span aria-label="sweat smile" class="emoji emoji-1f605" role="img" title="sweat smile">:sweat_smile:</span> I've said this before, but <code>align_of</code>/<code>size_of</code> are both super-early features that were not designed with our current understanding of stability. They are already causing problems (e.g. with <code>extern type</code>), and thus are not justification to create more APIs with the same pitfalls.</p>



<a name="209197005"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197005" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197005">(Sep 05 2020 at 21:37)</a>:</h4>
<p>I do agree(?) that giving generic code access to safe transmutation is quite a good goal. I just think that we shouldn't make the align_of/size_of problem any worse in doing so.</p>



<a name="209197056"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197056" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197056">(Sep 05 2020 at 21:39)</a>:</h4>
<p>To be fair, though, before I read the RFC I would not have been too upset by leaving the hole completely open, either! It's the in-between state that bothers me, where the API pays the complexity cost to avoid the hold but doesn't actually close it.</p>



<a name="209197099"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197099" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197099">(Sep 05 2020 at 21:40)</a>:</h4>
<p>(i.e. I would personally be open to considering <code>#[repr(C)]</code> sufficient to mark a type's layout as public)</p>



<a name="209197100"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197100" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197100">(Sep 05 2020 at 21:40)</a>:</h4>
<p>That's not back-compat. :(</p>



<a name="209197107"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197107" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197107">(Sep 05 2020 at 21:41)</a>:</h4>
<p>nobody ever actually officially articulated that's the case, so we can't apply that rule to old rust code.</p>



<a name="209197109"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197109" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197109">(Sep 05 2020 at 21:41)</a>:</h4>
<p>Ohh right in the sense that new, safe-transmute-using code could break by switching between two <em>already existing</em> old versions of a dep.</p>



<a name="209197114"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197114" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197114">(Sep 05 2020 at 21:41)</a>:</h4>
<p>Well that's sad but it doesn't really change the overall design space at this point I guess.</p>



<a name="209197160"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197160" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197160">(Sep 05 2020 at 21:42)</a>:</h4>
<p>that only affects people who #YOLO, <code>NeglectStability</code>, and transmute anyways</p>



<a name="209197164"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197164" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197164">(Sep 05 2020 at 21:42)</a>:</h4>
<p>retroactively changing the meaning of <code>repr(C)</code> would foist new stability requirements on everyone, including those who aren't transmuting</p>



<a name="209197224"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209197224" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209197224">(Sep 05 2020 at 21:44)</a>:</h4>
<p>It also occurs to me that a hypothetical <code>#[repr(pub)]</code> would, at a wishy-washy intuitive level, mirror what Swift does at API boundaries to let library authors choose between layout optimization and caller optimization.</p>



<a name="209203007"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209203007" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pachi <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209203007">(Sep 06 2020 at 01:13)</a>:</h4>
<p>Sorry if I misrepresent your proposal, <span class="user-mention" data-user-id="117495">@rpjohnst</span> , but what I understand is that you would like to flip who is in charge of allowing NeglectStability, from the destination type to the source type, by adding an intrinsic (transmute_safe), used to request that visibility breaking behavior (if allowed by the source type and requested by the user). That way the source type keeps visibility control and, possibly, only trait impls would be needed on it (probably mostly derived). Also, visibility breakage is contained at the language level (the intrinsic), with consent from the source type implementor.</p>
<p>Sorry you both of this is nonsense, I'm a total noobie, but find this conversation fascinating.</p>



<a name="209215105"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209215105" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209215105">(Sep 06 2020 at 08:17)</a>:</h4>
<p><span class="user-mention silent" data-user-id="132362">Joshua Liebow-Feeser</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209192590">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> </p>
<blockquote>
<p>NeglectStability indeed seems like a big can of worms</p>
</blockquote>
<p>Not sure I follow; what's the can of worms?</p>
</blockquote>
<p>I might be missing something, but doesn't this break semver? Any crate using <code>NeglectStability</code> risks failing to build/run after a semver-compatible update -- right? This is dangerously close to abstraction-breaking mechanisms such as reflection, an in the Rust ecosystem where our entire safety story relies on good non-leaky abstractions, that is playing with fire.</p>



<a name="209215169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209215169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209215169">(Sep 06 2020 at 08:20)</a>:</h4>
<blockquote>
<p>because, in principle, safety is orthogonal to stability.</p>
</blockquote>
<p>That is... maybe technically true but IMO not true in any useful way. There is a deep connection between good solid abstractions and the kind of safe encapsulation that Rust relies on. <a href="https://www.youtube.com/watch?v=8Xyk_dGcAwk">This talk</a> explains the connection:<br>
The gist is that if Rust had reflection, there would be no encapsulation of unsafe code behind a safe interface -- at least, not in any precise formal sense. Needless to say, Rust without safe encapsulation is basically a useless language. Reflection here is of course just a stand-in for any abstraction-breaking mechanism.</p>
<div class="youtube-video message_inline_image"><a data-id="8Xyk_dGcAwk" href="https://www.youtube.com/watch?v=8Xyk_dGcAwk"><img src="https://i.ytimg.com/vi/8Xyk_dGcAwk/default.jpg"></a></div>



<a name="209215310"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209215310" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209215310">(Sep 06 2020 at 08:24)</a>:</h4>
<p>I only skimmed the rest of the lively discussion, but the claim that stability and safety are orthogonal was repeated again and I just don't think that's a good view of things. Stability is closely tied to "abstraction" in the sense of "implementation details of a crate are not observable", and abstraction is <em>crucial</em> for Rust's safety story.</p>



<a name="209215376"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209215376" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209215376">(Sep 06 2020 at 08:27)</a>:</h4>
<p>Enough people have said that they need to "break" semver, and thereby basically break abstraction, for one reason or another that I cannot outright dismiss that usecase -- but I think the discussion of whether and how we want to explicitly support something like this should be separated from the rest of the RFC. Its concerns are way different, and it is much more likely to be controversial. It's not helpful to block the rest of the RFC on disagreements about how important stability is. That's why I called it a can of worms.</p>



<a name="209215482"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209215482" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209215482">(Sep 06 2020 at 08:31)</a>:</h4>
<p>Hm okay I guess the point of <code>NeglectStability</code> is that compilation is still guaranteed to fail if the assumptions the downstream crate is making are wrong? I'll have to think about how that changes things.</p>



<a name="209220648"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209220648" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209220648">(Sep 06 2020 at 11:12)</a>:</h4>
<p>After reading the RFC properly, I think I understand <code>NeglectStability</code> better now -- the point is that if this is used to break through an abstraction, and then later the "invaded" crate changes, we get a static compilation failure, not UB or so. That is still a big problem, but <em>on its own</em> does not impede safety.<br>
However, I remain worried about the larger ecosystem consequences -- will people start using <code>=1.2.3</code> dependencies to make block even semver-compatible updates? will that mean that soundness and other fixes have a harder time propagating through the ecosystem?</p>



<a name="209235132"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209235132" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209235132">(Sep 06 2020 at 18:03)</a>:</h4>
<p>Like an earlier comment in this discussion,I'm also wondering why NeglectStability is something the caller can specify, rather than some annotation on the source type.</p>



<a name="209235807"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209235807" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209235807">(Sep 06 2020 at 18:22)</a>:</h4>
<p>In a sense, it does require an annotation <code>#[repr(C)]</code> on the involved types.</p>
<p>The intuition is sorta like we're taking <code>core::mem</code> intrinsics and lifting them to a type-level. Just as whether <code>size_of::&lt;T&gt;() == 0</code> is satisfied isn't part of <code>T</code>'s stability guarantee, neither does whether the bound <code>T: TransmuteFrom&lt;(), NeglectStability&gt;</code> is satisfied. (We do try to make this instability a little more obvious in our RFC than it is with <code>size_of</code>, though.)</p>
<p>Unfortunately, I don't think any of us anticipated the argument that Rust perhaps <em>shouldn't</em> have had a general <code>size_of</code> function.</p>



<a name="209235991"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209235991" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209235991">(Sep 06 2020 at 18:27)</a>:</h4>
<p>It is <strong>not</strong> okay to use <code>NeglectStability</code> to break abstraction. Even with <code>NeglectStability</code>, you can only transmute into a type which is fully-implicitly constructable.</p>
<p>(Under the simplified formulation of constructability, this isn't <em>totally</em> enforced due to the pub-in-priv trick. We recommend that while the simplified formulation of constructability is used, the documentation for <code>PromiseTransmutable*</code> make <em>very</em> clear that these traits <em>must not</em> be implemented on any type using the pub-in-priv trick to restrict constructability! To do so anyways would be to violate the contract of <code>PromiseTransmutable*</code>.)</p>
<p>The RFC <em>does</em> pose a potential future <a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#design-of-neglectconstructability"><code>NeglectConstructability</code></a> option that <em>would</em> break abstraction. It's listed as out-of-scope precisely <em>because</em> it's an utter can-of-worms.</p>



<a name="209236145"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209236145" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209236145">(Sep 06 2020 at 18:31)</a>:</h4>
<p>I suppose the most-robust thing to do would be to mark the <code>PromiseTransmutable*</code> traits as unsafe for as long as the simplified version of constructability is used.</p>
<p>However, currently, making an <code>unsafe</code> trait safe is forbidden by rust—I'm not really sure why. E.g.:</p>
<div class="codehilite"><pre><span></span><code><span class="k">trait</span><span class="w"> </span><span class="n">Foo</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>

<span class="k">struct</span> <span class="nc">Bar</span><span class="p">;</span><span class="w"></span>
<span class="k">unsafe</span><span class="w"> </span><span class="k">impl</span><span class="w"> </span><span class="n">Foo</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">Bar</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>
</code></pre></div>


<div class="codehilite"><pre><span></span><code>error[E0199]: implementing the trait `Foo` is not unsafe
 --&gt; src/lib.rs:4:1
  |
4 | unsafe impl Foo for Bar {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
</code></pre></div>


<p>Is there a fundamental reason for this?</p>



<a name="209240631"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209240631" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209240631">(Sep 06 2020 at 20:35)</a>:</h4>
<p>What would be the point of that? You might be conflating the 2 meanings of unsafe here (ughh) - an unsafe on the implementation requires you to discharge a proof obligation specified by the trait, but if there is no such proof obligation, there is nothing to discharge.</p>



<a name="209240767"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209240767" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209240767">(Sep 06 2020 at 20:39)</a>:</h4>
<p>There <em>is</em>, arguably, a proof obligation with the simplified formulation of constructibility: that you are not bypassing the requirement of implicit constructibility with the pub in priv trick.</p>



<a name="209240886"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209240886" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209240886">(Sep 06 2020 at 20:42)</a>:</h4>
<p>So you'd need to mark the trait unsafe (and declare a proof obligation).</p>



<a name="209241136"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209241136" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209241136">(Sep 06 2020 at 20:51)</a>:</h4>
<p>That seems reasonable.</p>



<a name="209241248"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209241248" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209241248">(Sep 06 2020 at 20:54)</a>:</h4>
<p>If I'm reading this right, the proof obligation would be that all values allowed solely by a recursive field-check can be allowed, ie, no bitpatterns that rustc allows for a given field must be invalid due to library invariants?</p>
<p>Which in practice basically just rules out pub-in-priv?</p>



<a name="209241662"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209241662" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209241662">(Sep 06 2020 at 21:06)</a>:</h4>
<p>Under the simplified formulation of constructability, your proof obligation is that you don't implement <code>PromiseTransmutableFrom/Into</code> on your type if you are using the pub-in-priv trick to constrain its implicit constructability. This isn't asking a lot of end-users. If they're implementing <code>PromiseTransmutableFrom</code>, they're explicitly signaling that they promise their type should be instantiatable via transmutation—that's functionally equivalent to making the type itself fully implicitly constructable.</p>
<p>Under the full formulation of constructability, you don't have a manual proof obligation: the trait <code>bound</code> on <code>Archetype</code> enforces all safety properties.</p>



<a name="209241718"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209241718" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209241718">(Sep 06 2020 at 21:08)</a>:</h4>
<p>I apologize if this was discussed, I read the entire discussion but I may have been lost in the weeds. Is it difficult to enforce a full definition of constructability compiler wise? Ie, by treating any non fully constructible field as private.</p>



<a name="209241851"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209241851" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209241851">(Sep 06 2020 at 21:12)</a>:</h4>
<blockquote>
<p>Is it difficult to enforce a full definition of constructability compiler wise?</p>
</blockquote>
<p>In the general case, yeah. The problem is that to figure out whether a field type is implicitly constructable, you have to determine whether that type is visible from the perspective of whether the transmutation is occuring.</p>
<p>Because Rust permits the pub-in-priv trick, just because a field is <code>pub</code>, and its type is <code>pub</code> doesn't mean that field is <em>actually</em> visible: it could be inside a private module.</p>
<p>To resolve these sorts of situations, you need to actually take scope into account—it's not sufficient to just look for <code>pub</code> keywords on fields (which is exactly what the simplified formulation does).</p>



<a name="209241916"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209241916" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209241916">(Sep 06 2020 at 21:15)</a>:</h4>
<p>It's not inconceivable that Rust could do this <em>someday</em> (and there are some aspects of <code>TransmutableFrom</code> that probably make it slightly easier than a full-blown scoped-impls feature), and so the RFC is careful to be forwards-compatible with this possibility.</p>



<a name="209242019"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209242019" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209242019">(Sep 06 2020 at 21:18)</a>:</h4>
<p>It'd be a big undertaking, though, and I don't think it's practical to block safe transmutation efforts on implementing a complete formulation of constructability.</p>
<p>The pub-in-priv trick is rather niche, and if you're using it on a struct field, you're definitely doing so to restrict the struct's implicit constructability. If that's your intent, implementing <code>PromiseTransmutableFrom</code> is nonsensical, anyways.</p>



<a name="209246289"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209246289" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209246289">(Sep 06 2020 at 23:24)</a>:</h4>
<p>Got it. The only downside though is that you can't make an unsafe trait safe to implement without breakage (as you've discovered, so it'll probably be a blocker to stabilization either way.</p>



<a name="209246535"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209246535" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209246535">(Sep 06 2020 at 23:33)</a>:</h4>
<p>Not really. There's no fundamental issue with the trait remaining <code>unsafe</code> even after the full formulation of constructability is implemented, other than it being scarier-than-necessary to <code>impl</code>.</p>
<p>The limitation that you can't <code>unsafe</code> impl a safe trait seems totally artificial, too. That restriction could probably be lifted entirely, or special-cased for <code>PromiseTransmutable*</code> so it can be someday made safe without breaking old <code>unsafe</code> impls.</p>
<p>Regardless, this is probably <em>waaaaaay</em> off in the future.</p>



<a name="209247369"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209247369" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209247369">(Sep 06 2020 at 23:58)</a>:</h4>
<p>I also just realized that being fully implictly constructibke Repr-C structs limits any potential breakage with NeglectStability dramatically. I'm not sure what semver wrt to these types of structs says, but I doubt this will make any impact. There is not a lot you could/want to do with these restrictions in place.</p>



<a name="209249194"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209249194" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209249194">(Sep 07 2020 at 00:54)</a>:</h4>
<p>That's true, and a little frustrating. The <code>Archetype</code> system is expressive enough to let you pull tricks like adding new fields where there was padding, but the other side-effects of <code>pub</code> are <em>really</em> constricting: if all your fields are <code>pub</code>, you <em>can't</em> add a new field, because that breaks anybody pattern matching who isn't using <code>..</code>.</p>



<a name="209249836"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209249836" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209249836">(Sep 07 2020 at 01:17)</a>:</h4>
<p>So, you might very well add a private dummy field to a type, just to prevent people from fully-destructuring it—not to restrict its constructability. (heh, it's destructibility <em>vs</em> constructability...)</p>



<a name="209249881"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209249881" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209249881">(Sep 07 2020 at 01:18)</a>:</h4>
<p>I'm going to need to sleep on this. I think some of these use cases are covered by <a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#stability-of-unsafe-transmutations">forward-compat extension</a> to the RFC, which would allow type authors to make stable transmutations that neglect, e.g., constructability.</p>



<a name="209250711"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209250711" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209250711">(Sep 07 2020 at 01:45)</a>:</h4>
<p>I'm curious as to why the PromiseTransmutable traits themselves do not discharge the proof obligation of implicit constructability. I remember (though this may have been my imagination), that an early draft of the RFC stated that an archetype containing private fields would require NeglectValidity in order to transmute.</p>
<p>Sorry if this was asked already, but I scrolled through roughly 200 messages and didn't find a mention, and my zulip-fu isn't too good.</p>



<a name="209250772"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209250772" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209250772">(Sep 07 2020 at 01:47)</a>:</h4>
<blockquote>
<p>I remember (though this may have been my imagination), that an early draft of the RFC stated that an archetype containing private fields would require NeglectValidity in order to transmute.</p>
</blockquote>
<p>In an earlier draft, it required <code>NeglectVisibility</code>. Yeah, that got taken out. There's some prose on an equivalent "<code>NeglectConstructability</code>" though!</p>



<a name="209250814"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209250814" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209250814">(Sep 07 2020 at 01:48)</a>:</h4>
<p>The type bound of <code>Archetype</code> <em>does</em>, in theory, enforce implicit constructability.</p>



<a name="209250827"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209250827" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209250827">(Sep 07 2020 at 01:49)</a>:</h4>
<p>However, the simplified formulation of constructability has a soundness hole, so as long as the simplified formulation is used, the obligation not to abuse that soundness hole falls on <code>impl</code>s of <code>PromiseTransmutable*</code></p>



<a name="209250989"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209250989" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209250989">(Sep 07 2020 at 01:54)</a>:</h4>
<p><span class="user-mention silent" data-user-id="303115">Quy Nguyen</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209247369">said</a>:</p>
<blockquote>
<p>I also just realized that being fully implictly constructibke Repr-C structs limits any potential breakage with NeglectStability dramatically. I'm not sure what semver wrt to these types of structs says, but I doubt this will make any impact. There is not a lot you could/want to do with these restrictions in place.</p>
</blockquote>
<p>This observation makes me think there's a <em>really</em> good chance I'm going to be revisiting the stability traits.</p>
<p>If a type is implicitly constructible, it's <em>already</em> effectively stably transmutable (if its constituent parts are transmutable), since <em>all</em> of the details of the type are public. You can't do much, or <em>anything</em> to change it.</p>
<p>It's only when a type <em>isn't</em> implicitly constructible (i.e., it has private fields) that <code>PromiseTransmutable*::Archetype</code> gets interesting. If there's a private field, that means you <em>can</em>, for instance, add fields without breaking destructurings.</p>



<a name="209251042"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209251042" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209251042">(Sep 07 2020 at 01:56)</a>:</h4>
<p>(Gah. The range of things in Rust which can be breaking changes is staggeringly complex!)</p>



<a name="209296881"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209296881" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209296881">(Sep 07 2020 at 13:42)</a>:</h4>
<blockquote>
<p>If a type is implicitly constructible, it's already effectively stably transmutable (if its constituent parts are transmutable), since all of the details of the type are public. You can't do much, or anything to change it.</p>
</blockquote>
<p>You can reorder fields... and that's about it I think.^^ I guess one could argue that <code>repr(C)</code> promises field order stability but I am not sure if that is widely accepted.</p>



<a name="209316389"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209316389" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209316389">(Sep 07 2020 at 17:34)</a>:</h4>
<p>I can tell you that it's at least accepted among the various Discord communities for Rust.</p>



<a name="209319385"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209319385" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209319385">(Sep 07 2020 at 18:31)</a>:</h4>
<p>Hmm, just going to throw out some musings here.</p>
<p>The main thing to note here is that safe transmutation (with a layout guarantee) is logically identical to a recursive field-by-field transmute and calling implicit constructors. We get the observation that <span class="user-mention" data-user-id="219211">@Jack Wrenn</span> made that for a transmutation to be safe - the struct must be fully implicitly constructible. </p>
<p>An MVP for safe transmutation then, could completely <strong>ignore</strong> weak-stability guarantees - the only guarantee possible would be the one the derive makes. We could keep the RFC and NeglectStability exactly the same - the only break NeglectStabiliy could manifest would be field reorderings of a fully implicitly constructible <code>repr(C)</code> struct, which imo is in all honesty a very small issue.</p>
<p>Basically this is just a wall of text way of saying I think the only change we could make to NeglectStability would be to remove it - if it turns out field reordering is already a semver breaking change in this context.</p>



<a name="209320027"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209320027" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209320027">(Sep 07 2020 at 18:40)</a>:</h4>
<p>An even more MVP approach would be to ignore references and NeglectValidity/Alignment entirely (and go fully safe), but that might be a little bit heavy handed.</p>



<a name="209320143"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209320143" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209320143">(Sep 07 2020 at 18:41)</a>:</h4>
<p>MVP in the RFC doesn't necessarily include NeglectValidity/Alignment.</p>
<p>Ignoring references altogether is too minimal. They're not at all difficult to include, though.</p>



<a name="209321022"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209321022" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209321022">(Sep 07 2020 at 18:55)</a>:</h4>
<p>Oh wait, a reference transmutation could be made fully safe. Hmm, I think focusing on the safe API (+ the soundness hole) in the RFC, removing weak stability, and shunting the implementation over to a separate doc (modulo the soundness hole) would really help readability.</p>



<a name="209552173"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209552173" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209552173">(Sep 09 2020 at 18:51)</a>:</h4>
<p><span class="user-mention silent" data-user-id="219211">Jack Wrenn</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209250989">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="303115">Quy Nguyen</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility/near/209247369">said</a>:</p>
<blockquote>
<p>I also just realized that being fully implictly constructibke Repr-C structs limits any potential breakage with NeglectStability dramatically. I'm not sure what semver wrt to these types of structs says, but I doubt this will make any impact. There is not a lot you could/want to do with these restrictions in place.</p>
</blockquote>
<p>This observation makes me think there's a <em>really</em> good chance I'm going to be revisiting the stability traits.</p>
<p>If a type is implicitly constructible, it's <em>already</em> effectively stably transmutable (if its constituent parts are transmutable), since <em>all</em> of the details of the type are public. You can't do much, or <em>anything</em> to change it.</p>
<p>It's only when a type <em>isn't</em> implicitly constructible (i.e., it has private fields) that <code>PromiseTransmutable*::Archetype</code> gets interesting. If there's a private field, that means you <em>can</em>, for instance, add fields without breaking destructurings.</p>
</blockquote>
<p>These observations made me think that the bounds on <code>PromiseTransmutable*</code>'s <code>Archetype</code> should be relaxed such that <code>Self</code> <em>could</em> have private fields; e.g.:</p>
<div class="codehilite"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="k">trait</span><span class="w"> </span><span class="n">PromiseTransmutableFrom</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="bp">Self</span>::<span class="n">Archetype</span>: <span class="nc">PromiseTransmutableFrom</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">type</span> <span class="nc">Archetype</span>: <span class="nc">TransmuteInto</span><span class="o">&lt;</span><span class="bp">Self</span><span class="p">,</span><span class="w"> </span><span class="p">(</span><span class="n">NeglectConstructability</span><span class="p">,</span><span class="w"> </span><span class="n">NeglectStability</span><span class="p">)</span><span class="o">&gt;</span><span class="p">;</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>Then I realized this use-case is <em>already</em> supported with the current definitions under the full formulation of constructability. Your <code>Archetype</code> and <code>Self</code> <strong>are</strong> (usually) going to be fully implicitly constructible from the perspective of your <code>PromiseTransmutable*</code> impl, because they (usually) live right next to each other.</p>
<p>The full formulation of constructability really opens a lot of doors without further complicating the model or sacrificing the ability build type-level abstractions. <span aria-label="slight frown" class="emoji emoji-1f641" role="img" title="slight frown">:slight_frown:</span></p>



<a name="209566004"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209566004" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209566004">(Sep 09 2020 at 20:39)</a>:</h4>
<p>Rather than continuing to attack this problem from the angle of carefully compromising on safety, I'm curious if we can formulate full implicit constructability in a way that wouldn't actually be too impractical implement in the near-term.</p>
<p>Here's an idea:</p>
<ul>
<li>The compiler implements <code>T: Constructible&lt;S&gt;</code> if <code>T</code> is fully implicitly constructible in the scope <code>S</code>.</li>
<li>The <code>here!()</code> macro produces an opaque <code>Scope</code> type/value which uniquely represents the invocation scope of the macro.</li>
</ul>
<p>e.g.:</p>
<div class="codehilite"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="k">mod</span> <span class="nn">a</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="k">pub</span><span class="w"> </span><span class="k">struct</span> <span class="nc">Foo</span><span class="p">(</span><span class="n">private</span>::<span class="n">Bar</span><span class="p">);</span><span class="w"></span>

<span class="w">  </span><span class="k">mod</span> <span class="nn">private</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">pub</span><span class="w"> </span><span class="k">struct</span> <span class="nc">Bar</span><span class="p">;</span><span class="w"></span>
<span class="w">  </span><span class="p">}</span><span class="w"></span>

<span class="w">  </span><span class="n">assert_impl</span><span class="o">!</span><span class="p">(</span><span class="n">Foo</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">here</span><span class="o">!</span><span class="p">()</span><span class="o">&gt;</span><span class="p">);</span><span class="w">  </span><span class="c1">// Foo is fully implicitly constructible here</span>
<span class="p">}</span><span class="w"></span>

<span class="k">pub</span><span class="w"> </span><span class="k">mod</span> <span class="nn">b</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="k">use</span><span class="w"> </span><span class="k">super</span>::<span class="n">a</span>::<span class="n">Foo</span><span class="p">;</span><span class="w"></span>

<span class="w">  </span><span class="n">assert_not_impl</span><span class="o">!</span><span class="p">(</span><span class="n">Foo</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">here</span><span class="o">!</span><span class="p">()</span><span class="o">&gt;</span><span class="p">);</span><span class="w">  </span><span class="c1">// Foo isn&#39;t fully implicitly constructible here</span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>This has an ergonomic cost; you end up scope-passing e.g.:</p>
<div class="codehilite"><pre><span></span><code><span class="k">fn</span> <span class="nf">foo</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">S</span><span class="o">&gt;</span><span class="p">()</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">T</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">S</span><span class="o">&gt;</span><span class="w"> </span><span class="c1">// need to repeat bar&#39;s bound to call it</span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="n">bar</span><span class="p">()</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>

<span class="k">fn</span> <span class="nf">bar</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">S</span><span class="o">&gt;</span><span class="p">()</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">T</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">S</span><span class="o">&gt;</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="o">..</span><span class="p">.</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>...but I don't <em>think</em> it requires fundamentally reorganizing the type system in the way which a more implicit approach would.</p>



<a name="209568353"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209568353" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209568353">(Sep 09 2020 at 21:02)</a>:</h4>
<p>The scope-passing chore implies a slightly different API. Since we can't write:</p>
<div class="codehilite"><pre><span></span><code><span class="sd">/// error[E0207]: the type parameter `Scope` is not constrained by the impl trait, self type, or predicates</span>
<span class="k">impl</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Dst</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="n">TransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span><span class="o">&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">Dst</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="bp">Self</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">Dst</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="cm">/* ... */</span><span class="w"></span>
<span class="p">{}</span><span class="w"></span>
</code></pre></div>


<p>...we'd probably need to frame the RFC as three traits, instead:</p>
<div class="codehilite"><pre><span></span><code><span class="c1">// is the transmutation well-defined?</span>
<span class="k">pub</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="k">trait</span><span class="w"> </span><span class="n">SoundTransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>
<span class="cm">/* ^implemented purely with compiler magic */</span><span class="w"></span>


<span class="c1">// is the transmutation well-defined and safe?</span>
<span class="k">pub</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="k">trait</span><span class="w"> </span><span class="n">SafeTransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>

<span class="k">unsafe</span><span class="w"> </span><span class="k">impl</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Dst</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="n">SafeTransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">Dst</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">Src</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">Dst</span>: <span class="nc">Constructible</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="o">+</span><span class="w"> </span><span class="n">SoundTransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="p">{}</span><span class="w"></span>


<span class="c1">// Is the transmutation well-defined and stable?</span>
<span class="k">pub</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="k">trait</span><span class="w"> </span><span class="n">StableTransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>

<span class="k">unsafe</span><span class="w"> </span><span class="k">impl</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Dst</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="n">StableTransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">Dst</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="n">Src</span>: <span class="nc">PromiseTransmutableInto</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">Dst</span>: <span class="nc">PromiseTransmutableFrom</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="n">Dst</span>::<span class="n">Archetype</span>: <span class="nc">SafeTransmuteFrom</span><span class="o">&lt;</span><span class="n">Src</span>::<span class="n">Archetype</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="p">{}</span><span class="w"></span>
</code></pre></div>



<a name="209573531"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209573531" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209573531">(Sep 09 2020 at 21:55)</a>:</h4>
<p>The idea of scope-passing makes explicit a question that already exists in the non-scope-passing version: which location is used to determine whether a bound is satisfied? Today, when generic code tries to determine whether a bound is satisfied, it can look at both its own bounds and impls defined in its crate and dependencies. The difference between these two becomes the difference between forwarding a <code>Scope</code> parameter and using <code>here!()</code>.</p>
<p>This choice is quite fuzzy today - the compiler gives no indication which it chooses or why when both are available - because it currently makes no difference which one is used. Thus, it's plausible (and IMO quite likely) that the non-scope-passing version would need an equivalent mechanism anyway, because making impls depend on privacy makes this difference semantically meaningful.</p>



<a name="209671764"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209671764" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209671764">(Sep 10 2020 at 16:22)</a>:</h4>
<p>This seems promising. It totally gets rid of the hand-waving about implementing full formulation of implicit constructability and seems very feasible to implement.</p>
<p>The modifications to the API surface aren't too deep, either: <a href="https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=e758c5b17ce74108edc758c27497305a">https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=e758c5b17ce74108edc758c27497305a</a></p>



<a name="209679036"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209679036" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209679036">(Sep 10 2020 at 17:12)</a>:</h4>
<p>Should the <code>Promise..</code> traits perhaps <em>not</em> take a <code>Scope</code> parameter? As-is it seems like impls won't be able to "share" their <code>Here!()</code> type with clients, to let the primary type have private fields but still be transmutable via an archetype. (Or is that not supposed to work anyway?)</p>
<p>(I also see no impl for <code>TransmuteFrom&lt;Src, Scope, (NeglectConstructability,)&gt;</code>, despite it being used as a bound on line 48, is that maybe a typo?)</p>
<p>(Also, veering into bikeshed territory: the "tower" of trait impls on lines 27-49, each one removing one option from the one before it, kinda calls out to be turned into a chain of separate traits, similar to <code>trait Fn: FnMut</code>/<code>trait FnMut: FnOnce</code>/<code>trait FnOnce</code>.)</p>



<a name="209681633"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209681633" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209681633">(Sep 10 2020 at 17:35)</a>:</h4>
<blockquote>
<p>Should the <code>Promise..</code> traits perhaps not take a <code>Scope</code> parameter? </p>
</blockquote>
<p>I <em>think</em> we do, to accomodate generic containers; e.g.:</p>
<div class="codehilite"><pre><span></span><code><span class="k">impl</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="p">,</span><span class="w"> </span><span class="k">const</span><span class="w"> </span><span class="n">N</span>: <span class="kt">usize</span><span class="o">&gt;</span><span class="w"> </span><span class="n">PromiseTransmutableFrom</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">[</span><span class="n">T</span><span class="p">;</span><span class="w"> </span><span class="n">N</span><span class="p">]</span><span class="w"></span>
<span class="k">where</span><span class="w"></span>
<span class="w">    </span><span class="c1">// we definitely need a scope parameter for this, because `T` probably isn&#39;t in scope in libcore</span>
<span class="w">    </span><span class="n">T</span>: <span class="nc">PromiseTransmutableFrom</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>

<span class="w">    </span><span class="p">[</span><span class="n">T</span>::<span class="n">Archetype</span><span class="p">;</span><span class="w"> </span><span class="n">N</span><span class="p">]</span><span class="w"></span>
<span class="w">        </span>: <span class="nc">TransmuteInto</span><span class="o">&lt;</span><span class="bp">Self</span><span class="p">,</span><span class="w"> </span><span class="n">Scope</span><span class="p">,</span><span class="w"> </span><span class="n">NeglectStability</span><span class="o">&gt;</span><span class="w"></span>
<span class="w">        </span><span class="o">+</span><span class="w"> </span><span class="n">PromiseTransmutableFrom</span><span class="o">&lt;</span><span class="n">Scope</span><span class="o">&gt;</span><span class="p">,</span><span class="w"></span>
<span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">type</span> <span class="nc">Archetype</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="n">T</span>::<span class="n">Archetype</span><span class="p">;</span><span class="w"> </span><span class="n">N</span><span class="p">];</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="209681990"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209681990" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209681990">(Sep 10 2020 at 17:38)</a>:</h4>
<p>I'm not completely sure how well this works for types with multiple type parameters.</p>
<p>I think it might work fine.</p>



<a name="209684300"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209684300" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209684300">(Sep 10 2020 at 17:55)</a>:</h4>
<p>I'm imagining that impl would just write <code>T: PromiseTransmutableFrom</code> without a <code>Scope</code>, and rely on <code>T</code>'s own <code>PromiseTransmutableFrom</code> impl to use <em>its</em> own <code>Here!()</code> in its <code>TransmuteInto</code> bound.</p>



<a name="209684873"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209684873" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209684873">(Sep 10 2020 at 17:59)</a>:</h4>
<p>I think that would work, if it weren't for having to repeat <code>Archetype</code>'s bounds:</p>
<div class="codehilite"><pre><span></span><code>    [T::Archetype; N]
        : TransmuteInto&lt;Self, Scope, NeglectStability&gt;
</code></pre></div>


<p>The bound <code>[T::Archetype; N]: TransmuteInto&lt;Self, Here!(), NeglectStability&gt;</code> almost certainly wouldn't hold at the <code>impl</code> site, because <code>T</code> probably isn't reachable from the scope of the <code>impl</code>.</p>



<a name="209685548"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209685548" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209685548">(Sep 10 2020 at 18:03)</a>:</h4>
<p>But its Archetype should be, right?</p>



<a name="209685598"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209685598" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209685598">(Sep 10 2020 at 18:04)</a>:</h4>
<p>err, nevermind, of course not.</p>



<a name="209685707"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209685707" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209685707">(Sep 10 2020 at 18:04)</a>:</h4>
<p>Its Archetype should be reachable by the <em>client</em> of this impl, though- so maybe the impl needs a Scope param to forward to the TransmuteInto bound, but we don't really want to use that same Scope param in T: PromiseTransmutableFrom&lt;Scope&gt;, IIUC?</p>



<a name="209685832"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209685832" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209685832">(Sep 10 2020 at 18:05)</a>:</h4>
<p>That prooobably hits the unused param error though? (Can't try it out just now.)</p>



<a name="209685922"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209685922" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209685922">(Sep 10 2020 at 18:06)</a>:</h4>
<p>Haha, yep, it totally does.</p>



<a name="209686892"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209686892" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209686892">(Sep 10 2020 at 18:12)</a>:</h4>
<p>From an end-user perspective, we'd probably want to provide something like:</p>
<div class="codehilite"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="kr">macro</span><span class="w"> </span><span class="n">transmute</span><span class="p">(</span><span class="cp">$expr</span>: <span class="nc">expr</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="n">TransmuteFrom</span>::<span class="o">&lt;</span><span class="n">_</span><span class="p">,</span><span class="w"> </span><span class="n">Here</span><span class="o">!</span><span class="p">()</span><span class="o">&gt;</span>::<span class="n">transmute_from</span><span class="p">(</span><span class="cp">$expr</span><span class="p">)</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>So that you didn't have to think about any of this unless you were building a generic abstraction over <code>TransmuteFrom</code>.</p>



<a name="209843460"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209843460" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209843460">(Sep 11 2020 at 22:36)</a>:</h4>
<p>I've summarized some of this idea as a comment on the RFC: <a href="https://github.com/rust-lang/rfcs/pull/2981#discussion_r487319138">https://github.com/rust-lang/rfcs/pull/2981#discussion_r487319138</a></p>



<a name="209877661"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209877661" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209877661">(Sep 12 2020 at 11:41)</a>:</h4>
<p>I’m a big fan of the <code>transmute</code> macro! It’s looking like we can’t really do safe transmute abstractions you can build off without inventing new tools, and new tools need time to bake. A combination of <code>#[derive]</code> and <code>transmute!</code> seems like it would offer a useful starting point to get rubber on the road without painting ourselves into any corners or compromising any APIs we do want to offer. I’d be interested to see what other uses people would cook up for <code>Here!()</code></p>



<a name="209909716"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209909716" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209909716">(Sep 13 2020 at 02:14)</a>:</h4>
<p><span class="user-mention" data-user-id="204346">@Ashley Mannix</span> With today's updates, the RFC's suggested initial stabilization surface consists just of the derives and <code>transmute!</code>: <a href="https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#minimal-useful-stabilization-surface">https://github.com/jswrenn/rfcs/blob/safer-transmute/text/0000-safer-transmute.md#minimal-useful-stabilization-surface</a></p>



<a name="209909979"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Stability%20and%20visibility/near/209909979" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Stability.20and.20visibility.html#209909979">(Sep 13 2020 at 02:25)</a>:</h4>
<p>Having a stability roadmap is a great idea <span aria-label="smile" class="emoji emoji-1f642" role="img" title="smile">:smile:</span></p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>